Offline capture rejected by the server retries forever with no user-visible reason #108

New issue

Closed

opened 2026-07-15 19:52:54 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-15 19:52:54 +00:00

Contributor

Severity: Medium · Confidence: High · Effort: S · Category: ui

Evidence

app/src/hooks/useOfflineQueue.ts:83-104 - sync(): on res.ok === false (e.g. 400 validation or 401 after session expiry) the item is neither removed nor flagged; the catch only breaks for thrown/network errors.
app/src/components/layout/QuickCapture.tsx:406-411 - only a generic "N offline captures pending" banner.

Problem
A queued offline capture rejected by the server (content too long, session expired) is retried on every sync() (each 'online' event) indefinitely, with no error state exposed - the pending banner never resolves and never explains why.

Impact
A permanently stuck capture the user can neither see the reason for nor clear. Data limbo.

Fix
On !res.ok, capture the response and surface a per-item "failed to sync - " state, with a way to view/discard/edit the stuck item.

Acceptance criteria

A server-rejected offline capture surfaces a reason and can be cleared/edited.
It stops silently retrying forever.

Filed from the 2026-07-15 codebase audit. Full report: docs/.internal/report-2026-07-15.md (gitignored).

**Severity:** Medium · **Confidence:** High · **Effort:** S · Category: ui **Evidence** - `app/src/hooks/useOfflineQueue.ts:83-104` - `sync()`: on `res.ok === false` (e.g. 400 validation or 401 after session expiry) the item is neither removed nor flagged; the `catch` only `break`s for thrown/network errors. - `app/src/components/layout/QuickCapture.tsx:406-411` - only a generic "N offline captures pending" banner. **Problem** A queued offline capture rejected by the server (content too long, session expired) is retried on every `sync()` (each 'online' event) indefinitely, with no error state exposed - the pending banner never resolves and never explains why. **Impact** A permanently stuck capture the user can neither see the reason for nor clear. Data limbo. **Fix** On `!res.ok`, capture the response and surface a per-item "failed to sync - <reason>" state, with a way to view/discard/edit the stuck item. **Acceptance criteria** - [ ] A server-rejected offline capture surfaces a reason and can be cleared/edited. - [ ] It stops silently retrying forever. --- _Filed from the 2026-07-15 codebase audit. Full report: `docs/.internal/report-2026-07-15.md` (gitignored)._

claude-bot added this to the v7.3.0 - UI, mobile & accessibility milestone

2026-07-15 19:52:54 +00:00

claude-bot added the

bug

label

2026-07-15 19:52:54 +00:00

rbrooks referenced this issue from a commit

2026-07-17 22:48:57 +00:00

feat(v7.3.0): UI, mobile & accessibility milestone

rbrooks referenced this issue from a commit

2026-07-17 22:55:42 +00:00

test(v7.3.0): update offline-queue tests for #108 failed-item behavior

claude-bot commented

2026-07-17 23:14:15 +00:00

Author

Contributor

A server-rejected offline capture (400/401) is now captured with its reason, flagged so auto-sync skips it (no more infinite silent retry), and surfaced in a panel with per-item Retry (e.g. after re-login) and Discard. pendingCount excludes flagged items so the banner can reach zero. Covered by new tests (no-auto-retry, retry, discard).

Shipped in 59e4fdd (test fix 6561f9a), part of the v7.3.0 milestone. Verified on dev (v7.2.1-3-g6561f9a): app suite 65/65 and api suite 268/268 green on the dev server; the one CI red was the known runner flake (iac#159), not this change.

A server-rejected offline capture (400/401) is now captured with its reason, flagged so auto-sync **skips** it (no more infinite silent retry), and surfaced in a panel with per-item **Retry** (e.g. after re-login) and **Discard**. `pendingCount` excludes flagged items so the banner can reach zero. Covered by new tests (no-auto-retry, retry, discard). Shipped in `59e4fdd` (test fix `6561f9a`), part of the v7.3.0 milestone. Verified on dev (`v7.2.1-3-g6561f9a`): app suite 65/65 and api suite 268/268 green on the dev server; the one CI red was the known runner flake (iac#159), not this change.

claude-bot closed this issue

2026-07-17 23:14:15 +00:00