REL-NB-005 — Keep failed saves visible and retryable
| Field | Value |
|---|---|
| Status | Open; source-verified |
| Architecture state | Source-backed current behavior |
| Severity | Critical |
| Affected surface | Autosave, manual save, reload guard, close, and retry |
| Components | sparqd/oqullus; Workspace file API is downstream |
| Associated issue | oqullus #518 |
Where the problem appears
Force the notebook update request to fail during autosave and manual save, then attempt navigation, reload, and close.
Concrete observed case
The save operation catches update errors and resolves instead of rejecting. Silent autosave shows no durable error, and callers can clear dirty state after the unsuccessful request. Retry settings exist but are not used by the reviewed autosave flow.
Expected condition
A failed write retains the dirty revision, displays persistent Save failed — Retry, and blocks destructive navigation until persistence succeeds or the user explicitly discards the changes.
Cause and evidence
Failure is converted into successful control flow, so later dirty-state and close logic cannot distinguish accepted persistence from a rejected request.
Why it matters
Users can lose code and output while the product appears saved and removes its own reload or navigation protection.
Existing controls and workarounds
Manual save may show a transient toast. Verify persisted content or history before leaving after any network or service failure.
Alternatives considered
- Recommended: return a typed failure, retain dirty state, expose retry, and allow one in-flight save per notebook.
- Retry every failure automatically — rejected because authorization, payload, and conflict failures are not safely retryable.
- Show only a toast — insufficient because the document remains at risk after the toast disappears.
Component involvement
sparqd/oqullusowns failure propagation, persistent save state, retry policy, and navigation/close gating.- Workspace file API returns the authoritative acceptance or error.
Reproduction and verification
Follow NB-S017.
Resolution conditions
Close when network, authorization, payload, conflict, and upstream failures all retain dirty state and recover through explicit, bounded behavior.
Validation and blockers
Source behavior is confirmed. Deployed failure injection must use a disposable notebook without risking user content.