cleveragents/cleveragents-core

Fork 3

UAT: `agents project unlink-resource` fails if resource has been deleted — cannot clean up dangling links #5534

New issue

Open

opened 2026-04-09 07:14:39 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-09 07:14:39 +00:00

Owner

Bug Report

Feature Area: projects-resources
Severity: High — operational deadlock when resource is deleted before unlinking
Milestone: v3.0.0+

What Was Tested

agents project unlink-resource behavior when the linked resource has been deleted from the registry.

Expected Behavior (from spec)

Per docs/specification.md line 229:

agents project unlink-resource [--yes|-y] <PROJECT> <RESOURCE_NAME>

The command should be able to unlink a resource by name even if the resource record no longer exists in the registry. The <RESOURCE_NAME> argument should be resolvable to a link record directly.

Actual Behavior (from code analysis)

In src/cleveragents/cli/commands/project.py lines 754–759, the implementation first tries to look up the resource in the registry:

# Resolve resource
try:
    res = registry.show_resource(resource_name)
except NotFoundError as exc:
    err_console.print(f"[red]Resource not found:[/red] {resource_name}")
    raise typer.Exit(1) from exc

If the resource has been deleted (e.g., via a bug like #5482 where resource remove doesn't check project links), the show_resource call raises NotFoundError and the command exits with an error. The user is then stuck with a dangling link that cannot be removed.

Scenario

Resource local/my-repo is linked to project local/my-project
Resource local/my-repo is deleted (via resource remove bypassing the project link check — see #5482)
User tries: agents project unlink-resource local/my-project local/my-repo
Expected: Unlink succeeds (removes the dangling link record)
Actual: Error "Resource not found: local/my-repo" — user cannot clean up the dangling link

Code Location

src/cleveragents/cli/commands/project.py, lines 723–804 (unlink_resource function)

Fix Required

The unlink-resource command should handle the case where the resource no longer exists. When show_resource raises NotFoundError, the command should fall back to searching the project's link records directly by name:

try:
    res = registry.show_resource(resource_name)
    resource_id = res.resource_id
except NotFoundError:
    # Resource deleted — search links by name directly
    links = link_repo.list_links(proj.namespaced_name)
    # Try to match by stored resource name in the link record
    # (requires link records to store the resource name at link time)
    resource_id = None  # Cannot resolve — need link record enhancement

This may require storing the resource name in the link record at link time, or providing a --resource-id flag as an alternative to --resource-name.

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

## Bug Report **Feature Area**: projects-resources **Severity**: High — operational deadlock when resource is deleted before unlinking **Milestone**: v3.0.0+ ### What Was Tested `agents project unlink-resource` behavior when the linked resource has been deleted from the registry. ### Expected Behavior (from spec) Per `docs/specification.md` line 229: ``` agents project unlink-resource [--yes|-y] <PROJECT> <RESOURCE_NAME> ``` The command should be able to unlink a resource by name even if the resource record no longer exists in the registry. The `<RESOURCE_NAME>` argument should be resolvable to a link record directly. ### Actual Behavior (from code analysis) In `src/cleveragents/cli/commands/project.py` lines 754–759, the implementation first tries to look up the resource in the registry: ```python # Resolve resource try: res = registry.show_resource(resource_name) except NotFoundError as exc: err_console.print(f"[red]Resource not found:[/red] {resource_name}") raise typer.Exit(1) from exc ``` If the resource has been deleted (e.g., via a bug like #5482 where `resource remove` doesn't check project links), the `show_resource` call raises `NotFoundError` and the command exits with an error. The user is then stuck with a dangling link that cannot be removed. ### Scenario 1. Resource `local/my-repo` is linked to project `local/my-project` 2. Resource `local/my-repo` is deleted (via `resource remove` bypassing the project link check — see #5482) 3. User tries: `agents project unlink-resource local/my-project local/my-repo` 4. **Expected**: Unlink succeeds (removes the dangling link record) 5. **Actual**: Error "Resource not found: local/my-repo" — user cannot clean up the dangling link ### Code Location - `src/cleveragents/cli/commands/project.py`, lines 723–804 (`unlink_resource` function) ### Fix Required The `unlink-resource` command should handle the case where the resource no longer exists. When `show_resource` raises `NotFoundError`, the command should fall back to searching the project's link records directly by name: ```python try: res = registry.show_resource(resource_name) resource_id = res.resource_id except NotFoundError: # Resource deleted — search links by name directly links = link_repo.list_links(proj.namespaced_name) # Try to match by stored resource name in the link record # (requires link records to store the resource name at link time) resource_id = None # Cannot resolve — need link record enhancement ``` This may require storing the resource name in the link record at link time, or providing a `--resource-id` flag as an alternative to `--resource-name`. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 07:15:07 +00:00

HAL9000 added a new dependency

2026-04-09 07:33:12 +00:00

#5203 EPIC: CLI Output Format Compliance — Global Flags, JSON Envelope & Error Responses

HAL9000 referenced this issue

2026-04-09 07:38:07 +00:00

[AUTO-EPIC] Epic Planning Health Report (Cycle 11) #5298

HAL9000 referenced this issue

2026-04-09 07:40:05 +00:00

Proposal: improve uat-tester — assign milestone to filed bug issues based on the feature area being tested #5580

HAL9000 referenced this issue

2026-04-09 08:20:03 +00:00

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

HAL9000 added the

State

Verified

label

2026-04-09 10:16:37 +00:00

HAL9000 commented

2026-04-09 10:20:38 +00:00

Author

Owner

🏷️ Label Fix Applied by Backlog Groomer

The State/Verified label has been added to this issue.

Reason: During a routine backlog grooming pass, this issue was found to have Type/Bug and a Priority/ label but was missing a State/* label entirely — a violation of the CONTRIBUTING.md requirement that every issue must have exactly one State/ label.

Since this issue has been triaged with a priority and type, State/Verified is the appropriate state: the issue has been confirmed as legitimate and is now part of the active backlog.

No other changes were made.

Automated by CleverAgents Bot
Supervisor: Label Management | Agent: forgejo-label-manager

## 🏷️ Label Fix Applied by Backlog Groomer The `State/Verified` label has been added to this issue. **Reason**: During a routine backlog grooming pass, this issue was found to have `Type/Bug` and a `Priority/` label but was missing a `State/*` label entirely — a violation of the CONTRIBUTING.md requirement that every issue must have exactly one `State/` label. Since this issue has been triaged with a priority and type, `State/Verified` is the appropriate state: the issue has been confirmed as legitimate and is now part of the active backlog. No other changes were made. --- **Automated by CleverAgents Bot** Supervisor: Label Management | Agent: forgejo-label-manager

HAL9000 referenced this issue

2026-04-09 12:09:11 +00:00

[AUTO-GROOMER] Backlog Grooming Report (Cycle 59) #5949