Should a notification failure force the user to save an order again? What remains when an upload completed but publication was rejected?
I read each completed boundary separately. The local lab implements queued notification and simulated delivery failure; the site’s package correction provides a different real partial-completion record.
Write down what has actually committed
Document storage, upload completion, file linkage, notification scheduling and delivery are different facts. One interface sequence may involve several stores. Restarting from the first button without identifying completed steps can duplicate records or files. I look for the remaining work outside the result already confirmed.
The SQLite lab commits the document, event and follow-up queue together. It does not implement an attachment server. This site’s upload and publication services have their own separate states. I use the shared question of remaining work without presenting these two examples as one integrated system.
A pre-commit error rolls back the local group
fail_before_commit injects an error after proposed document, event, queue and request-result writes but before commit. Everything rolls back. The test checks the initial document version and absence of partial rows in the other tables. It defines which evidence must exist together before a save can be reported as committed.
That test does not roll back a remote file or email service. A flag in a local transaction cannot settle another storage system’s operations. Local atomicity is one verified piece; follow-up recovery, retention and cleanup require their own policies. Establish the actual shared boundary before implementing an apparently unified action.
Post-save delivery failure should not mutate the order again
A separate test commits the document and queue, then records simulated failed delivery. Updating only the delivery outcome does not add another document event. Retrying a notification is not allowed to become another quantity mutation. This separation makes the recovery point easier to explain.
It does not authorize blind retries of every notification. Definitive failure differs from unknown receipt, and unknown delivery stops in this lab. Provider lookup, delays, retry limits and operator reconciliation remain unimplemented. The test establishes separation of local business events and simulated follow-up status, not a real delivery service.
Read the site’s unreferenced file as a different example
During the earlier policy-module publication, a code property was mistaken for an external address and the manuscript write was rejected after its package upload completed. I preserved the publication checks, renamed the synthetic field, reviewed a corrected package and removed review approval from the unreferenced earlier object. Only the new file was published; the old public URL returned 404.
That ordering differs from a successful save followed by a failed attachment. I do not claim it reproduced the same outage. It is actual evidence that completed upload, manuscript reference and public eligibility need separate checks. Retaining the unreferenced file rather than immediately deleting it also preserved evidence and backup scope, without publishing or deleting client records.
Show the remaining work to the operator
A generic total failure can ask staff to repeat completed actions. Use supported facts such as stored, attachment link awaiting review or notification not delivered, with a corresponding next action. Unknown stages must not receive invented success markers. The wording should identify the result that was actually checked.
The package supplies tests for separated document and delivery state. The site correction remains privately evidenced and is described without company data. No external message or operational ERP recovery was performed. I share where careful separation of finished and remaining work is more useful than automatically restarting the entire process.