An error on a save screen invites another click. If the server committed before the response disappeared, that second request needs to preserve the original intent.
Instead of claiming a network fault test, I ignored a synthetic command’s returned result and reopened its database. The experiment checks recovery of persisted outcomes, with its narrower scope stated explicitly.
No response does not prove no processing
Validation rejection did not change a document. A rolled-back transaction did not commit either. A committed save whose response was not received is different. I did not combine these into one failure that automatically creates another request. The first question is whether the original intent has a recoverable outcome.
The test reopens the same database in another WorkflowLab instance and repeats identical company, user, key and command. It receives the stored result. That verifies persistence and replay after reopening, not a physical network interruption. Keeping those scopes distinct prevents a local demonstration from becoming an unsupported claim about an entire outage strategy.
Confirm the same intent without changing it
Changing quantity or expected version while reusing the original key mixes two intents. The package rejects a different fingerprint under that key. The client must retain enough information to reconstruct the original request. An edited command is a new intent; checking the earlier result keeps the earlier command unchanged.
The replayed document is a snapshot from that request’s completion. It may differ from current state after later edits. Finding the outcome is not permission to overwrite an editor’s newest draft with that snapshot. Completion of a request, the latest stored document and an unsaved draft belong to different state boundaries.
Read a committed receipt before treating a retry as stale
A command based on version zero may have produced version one. Its repeated expected version is now old, but returning only a version conflict would obscure the first success. After checking the trusted context and document scope, the lab looks for the matching committed request result before performing a new version comparison.
That does not authorize every stale-screen operation. Another key or changed content represents a new command and must satisfy current state and version requirements. Another user also cannot recover a result by key alone. Replay is a narrow path for the same principal’s same intent, not an authorization bypass.
Define lookup and retry policy separately
This implementation supplies safe replay of the same command, not an independent request-status API. A real service may benefit from a dedicated outcome lookup. It must define what establishes processing, completion, definitive failure or an unknown result using the store and provider contracts. Interface wording alone cannot manufacture those facts.
External delivery requires another boundary. Sending again when receipt is unknown may duplicate the document. The lab does not automatically retry unknown delivery, and implements no provider status query or operator reconciliation service. Recovering a local request result is not proof that every external operation completed.
Preserve the user’s next decision
While outcome checking continues, preserving the draft and showing a recovery path can be more useful than returning an empty form. The design should distinguish creating another save from checking an earlier one. The lab verifies agreement between stored receipts and document changes; the connected screen still needs its own review.
Tests check the same event sequence after reopening and the absence of an extra mutation, alongside changed-content key reuse and pre-commit failure. No company records or external traffic are involved. I share the facts worth rereading before another action, rather than presenting aggressive retrying as the solution.