DATA-ONT-002 — Define workbook persistence
| Field | Value |
|---|---|
| Status | Open finding; source-verified; multi-session test pending |
| Severity | High |
| Components | sparqd/ontology, sparqd/oqullus |
| Associated issues | Not opened pending finding review |
Concrete observed case
Query fields, filters, order, and limit remain local until a successful Run, after which Oqullus starts an unacknowledged PATCH and discards failures. Chart changes save immediately; Reset does not save; names save explicitly; dashboard membership waits for Save Dashboard. There is no dirty state, recovery draft, revision, ETag, or conflict response. Reload restores the last successful saved query and runs it, which may not match the state visible before reload.
Dashboard membership is a JSON list of tab IDs. Arbitrary, missing, foreign, or duplicate references are not consistently rejected, and deleting a tab does not transactionally remove it from dashboards.
Expected condition
One documented save contract covers every editable field, visibly reports saving/saved/failed/conflicted state, supports retry or draft recovery, and uses optimistic concurrency. Dashboard membership and ordering remain valid through create, delete, reorder, and concurrent updates.
Why it matters
Users can believe changes were saved when the write failed, lose a newer edit to another session, or reopen a workbook that executes an older query.
Existing controls and workarounds
Name changes show failures. A successful query generally triggers query-config persistence. Neither provides a complete save or concurrency guarantee.
Alternatives considered
- Recommended: explicit Save for query/dashboard definitions with dirty state, optimistic concurrency, and recoverable local draft.
- Coherent autosave with debounce, acknowledgement, revisions, and retry.
- Save on Run — conflates execution success with authoring persistence and cannot preserve an invalid or unfinished draft.
Component involvement
- Oqullus implements one visible save-state machine and recovery experience.
- Ontology backend validates associations and enforces revisions atomically.
Reproduction and verification
Resolution conditions
Close when all fields follow the declared contract, failures cannot be silent, two sessions cannot overwrite unnoticed, and tab/dashboard invariants hold.
Validation and blockers
The mixed save paths and missing constraints are source-confirmed. Controlled multi-session live evidence remains pending.