UAT: `DatabaseResourceHandler` declares `checkpoint: False` in type defs but fully implements checkpoint/rollback methods — capability flag contradicts implementation #5874

New issue

Open

opened 2026-04-09 11:16:57 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-09 11:16:57 +00:00

Owner

Bug Report

Feature Area: Resource Management — Database Resources
Milestone Scope: v3.6.0 (database resource handler, issue #1241)
Severity: Medium — capability flag mismatch causes incorrect tool/UI behavior

What Was Tested

Code-level analysis of src/cleveragents/resource/handlers/database.py against the spec and the built-in type definitions.

Expected Behavior (from spec)

The capabilities dict on each resource type definition should accurately reflect what the handler supports. Per docs/reference/resource_types_builtin.md and the spec, the checkpoint capability flag controls whether checkpoint/rollback operations are available for a resource type.

If checkpoint: False, the system should not offer checkpoint/rollback for that type.

Actual Behavior

All four database type definitions (POSTGRES_TYPE_DEF, MYSQL_TYPE_DEF, SQLITE_TYPE_DEF, DUCKDB_TYPE_DEF) in database.py declare:

"capabilities": {
    "read": True,
    "write": True,
    "sandbox": True,
    "checkpoint": False,   # ← WRONG
},

However, DatabaseResourceHandler fully implements create_checkpoint() and rollback_to() methods (added in issue #1241):

SQLite: Creates real SAVEPOINT transactions and rolls back via ROLLBACK TO SAVEPOINT
Remote DBs: Falls back to content-hash checkpoints

The checkpoint: False flag is therefore incorrect — the handler does support checkpoints.

Code Location

Type definitions: src/cleveragents/resource/handlers/database.py lines ~30–130 (POSTGRES_TYPE_DEF, MYSQL_TYPE_DEF, SQLITE_TYPE_DEF, DUCKDB_TYPE_DEF)
Handler implementation: src/cleveragents/resource/handlers/database.py DatabaseResourceHandler.create_checkpoint() and rollback_to()

Steps to Reproduce

Read SQLITE_TYPE_DEF["capabilities"]["checkpoint"] → returns False
Read DatabaseResourceHandler.create_checkpoint.__doc__ → shows full SQLite SAVEPOINT implementation
Contradiction: capability says no checkpoint, but handler implements it

Impact

Any system component that checks capabilities["checkpoint"] before calling create_checkpoint() will incorrectly skip checkpoint operations for database resources
UI/CLI tools that display available capabilities will show checkpoint as unavailable even though it works
The spec (issue #1241) explicitly added checkpoint support — the capability flag was not updated to match

Fix

Update all four database type definitions to set "checkpoint": True:

"capabilities": {
    "read": True,
    "write": True,
    "sandbox": True,
    "checkpoint": True,   # ← correct: handler implements SAVEPOINT for SQLite
},

Note: For remote databases (postgres, mysql), rollback_to() returns success=False with a "not supported" message. If the intent is that only SQLite supports checkpoints, then sqlite and duckdb should have checkpoint: True while postgres and mysql keep checkpoint: False. Either way, the current state (all False) is wrong for SQLite.

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Bug Report **Feature Area**: Resource Management — Database Resources **Milestone Scope**: v3.6.0 (database resource handler, issue #1241) **Severity**: Medium — capability flag mismatch causes incorrect tool/UI behavior --- ## What Was Tested Code-level analysis of `src/cleveragents/resource/handlers/database.py` against the spec and the built-in type definitions. ## Expected Behavior (from spec) The `capabilities` dict on each resource type definition should accurately reflect what the handler supports. Per `docs/reference/resource_types_builtin.md` and the spec, the `checkpoint` capability flag controls whether checkpoint/rollback operations are available for a resource type. If `checkpoint: False`, the system should not offer checkpoint/rollback for that type. ## Actual Behavior All four database type definitions (`POSTGRES_TYPE_DEF`, `MYSQL_TYPE_DEF`, `SQLITE_TYPE_DEF`, `DUCKDB_TYPE_DEF`) in `database.py` declare: ```python "capabilities": { "read": True, "write": True, "sandbox": True, "checkpoint": False, # ← WRONG }, ``` However, `DatabaseResourceHandler` **fully implements** `create_checkpoint()` and `rollback_to()` methods (added in issue #1241): - **SQLite**: Creates real `SAVEPOINT` transactions and rolls back via `ROLLBACK TO SAVEPOINT` - **Remote DBs**: Falls back to content-hash checkpoints The `checkpoint: False` flag is therefore incorrect — the handler does support checkpoints. ## Code Location - Type definitions: `src/cleveragents/resource/handlers/database.py` lines ~30–130 (`POSTGRES_TYPE_DEF`, `MYSQL_TYPE_DEF`, `SQLITE_TYPE_DEF`, `DUCKDB_TYPE_DEF`) - Handler implementation: `src/cleveragents/resource/handlers/database.py` `DatabaseResourceHandler.create_checkpoint()` and `rollback_to()` ## Steps to Reproduce 1. Read `SQLITE_TYPE_DEF["capabilities"]["checkpoint"]` → returns `False` 2. Read `DatabaseResourceHandler.create_checkpoint.__doc__` → shows full SQLite SAVEPOINT implementation 3. Contradiction: capability says no checkpoint, but handler implements it ## Impact - Any system component that checks `capabilities["checkpoint"]` before calling `create_checkpoint()` will incorrectly skip checkpoint operations for database resources - UI/CLI tools that display available capabilities will show checkpoint as unavailable even though it works - The spec (issue #1241) explicitly added checkpoint support — the capability flag was not updated to match ## Fix Update all four database type definitions to set `"checkpoint": True`: ```python "capabilities": { "read": True, "write": True, "sandbox": True, "checkpoint": True, # ← correct: handler implements SAVEPOINT for SQLite }, ``` Note: For remote databases (postgres, mysql), `rollback_to()` returns `success=False` with a "not supported" message. If the intent is that only SQLite supports checkpoints, then `sqlite` and `duckdb` should have `checkpoint: True` while `postgres` and `mysql` keep `checkpoint: False`. Either way, the current state (all False) is wrong for SQLite. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 11:43:22 +00:00

HAL9000 referenced this issue

2026-04-09 12:03:27 +00:00

[AUTO-ARCH] Architecture Review (Cycle 1) #5767

~~HAL9000 referenced this issue 2026-04-09 12:21:22 +00:00~~

[AUTO-UAT-POOL] UAT Testing Report (Cycle 1) #5750