[BUG] Failed activity item cannot be dismissed, API returns 409 because row remains active

[Cylac]

Bug Description

A failed or interrupted audiobook item appeared in the Failed section of Activity, but it could not be cleared from the UI.

When clicking Clear, the browser Network tab showed:
POST /api/activity/dismiss-many

The response was:
409 Conflict
Only terminal downloads can be dismissed

The issue appears to be a state mismatch. The item was shown in Failed in the UI, but the matching row in users.db under download_history was still marked as final_status = active.

Steps To Reproduce

1. Request an audiobook in Shelfmark.
2. Let the request end up in a failed or interrupted state so it appears under Failed in Activity.
3. Try to clear the failed item from the UI.
4. Observe that the dismiss request fails with 409 Conflict and the message Only terminal downloads can be dismissed.

Expected Behavior

If an item appears in the Failed section of Activity, it should be dismissible from the UI.

Alternatively, if the backend still considers the item non terminal, it should not appear in Failed.

Debug Information

DEBUG=true was enabled.

I did not see a useful backend error in the Shelfmark container logs when reproducing the issue.

The browser Network tab showed:
POST /api/activity/dismiss-many
409 Conflict
Only terminal downloads can be dismissed

Manual database inspection showed the failed UI item was still stored as active in download_history.

Example row before manual cleanup:

• content_type: audiobook
• final_status: active

Manual workaround that removed the ghost item:

1. Backed up users.db
2. Deleted the stale download_history row
3. Refreshed Shelfmark
4. The failed item disappeared from the UI

Environment Information

• BASE OS: Ubuntu
• Shelfmark version: v1.2.0
• Docker deployment: Yes

docker-compose

services:
shelfmark:
image: ghcr.io/calibrain/shelfmark:latest
container_name: shelfmark
restart: unless-stopped
environment:
- TZ=America/Toronto
- DEBUG=true

Additional Context

The browser Network tab captured the failing dismiss call clearly.

This looks like a backend state mismatch between:

• how the item is classified in the UI, and
• how its terminal state is stored and validated by the dismiss endpoint

The stale entry causing the issue was found in download_history, where the item was still marked active even though it appeared in Failed in the UI.