Define the failure model first
Define failures for browser requests, missing receipts, reloads, reopened tabs, and server errors. Also define failures for duplicate requests, incorrect event order, deadlines, and old tabs.
Browser responsibility: preserve intent before send
Write response events, item snapshots, and submit requests to local storage before network transmission. An in-memory queue cannot survive a reload or tab close. The local record needs an attempt identity, sequence, event type, payload, creation time, and receipt state.
- Tell the learner when local work does not have server confirmation.
- Restore pending work when the assessment reloads.
- Replay in a defined sequence when connectivity returns.
- Prune local records only after receipt coverage proves durable acceptance.
Server responsibility: make retries safe
Give each client request a stable identifier or sequence. The attempt authority accepts a duplicate without a second event. It rejects an unauthorized attempt and returns the receipt status.
Final submit is a durable state change. The platform records the submission and issues a receipt. Scoring, exports, grade return, and reporting continue after this operation.
Authority responsibility: resolve stale tabs and deadlines
| Condition | Required behavior | Evidence |
|---|---|---|
| Duplicate tab | One attempt authority determines writable state and projects stale state back. | Tab identity, rejected stale sequence, and current attempt projection. |
| Late replay | Use the delivery policy to accept, flag, or reject the event. Keep the event record. | Client creation time, server acceptance time, policy decision, and receipt. |
| Repeated submit | Return the same submitted state and receipt coverage. | Idempotency record and durable attempt status. |
| Post-submit correction | Preserve original responses and apply auditable scoring or policy operations. | Original ledger, correction record, and projected result. |
Test recovery as a sequence, not a screenshot
- Save an answer offline, restore the connection, and confirm receipt coverage advances.
- Queue the final response and submit intent, reload, and confirm both remain pending.
- Close and reopen the tab before reconnect, then confirm ordered replay.
- Return retryable server failures and verify the browser retains unconfirmed work.
- Open a second tab and prove stale writes cannot replace authoritative state.
- Replay near and after a deadline and verify the policy decision remains auditable.
Give instructors usable evidence
The event record gives creation, receipt, retry, sequence, submit, and policy data. Support teams use this data to explain the recovery result.
QFlowLearn recovery evidence
QFlowLearn documents local IndexedDB journaling, ordered replay, durable receipts, attempt authority, and stale-tab reconciliation on the network recovery evidence page. The delivery overview places that browser behavior inside the wider publication, attempt, submit, scoring, and reporting path.