Recover lost responses and stale proposals
A failed or missing response does not always mean an operation failed. Donation creation and financial commands keep an original request identity so a retry can resolve the same intent without creating another receipt or journal.
Unresolved creation
If Unresolved creation request appears, use Retry original creation. It resends the original body and key. Do not change the form, start another gift or clear browser storage to bypass the pending intent.
After a successful replay, inspect the saved donation. A creation replay describes the original creation result; refresh the current record before making a later decision if it has since changed.
Unresolved financial operation
- Return to the donation named by the unresolved operation.
- Confirm you still hold the relevant access.
- Choose Retry original operation once and wait.
- Allow the stored original body/key to be sent unchanged.
- Refresh detail and history to establish the resulting state.
- Start a different action only after the existing intent is resolved.
The browser stores the intent in session storage scoped by tenant and username. It is recovery assistance, not a server queue or a guarantee that closing the tab/device preserves it. If browser storage is blocked, the application reports that no command was sent when it cannot persist the intent first. Do not manually manipulate stored request contents.
Stale proposal versus unknown outcome
| Message/code | Next step |
|---|---|
| STALE_DONATION_VERSION | Reload current donation and reconcile changes |
| CALENDAR_CHANGED | Reload settings/date and generate a new reviewed preview |
| POSTING_PREVIEW_CHANGED | Review current route/mapping/policy and regenerate proposal |
| ALREADY_POSTED | Inspect saved posting; do not submit a new post |
| DONATION_NOT_POSTED | Reload state and choose an eligible action |
| CANONICAL_RECEIPT_HAS_DEPENDENTS | Review duplicate links; do not force canonical reversal |
| Network/server error with pending intent | Preserve and retry the original request |
| Access revoked | Reconcile authorised access with the administrator; replay cannot bypass revocation |
The application distinguishes refresh-required conflicts from unresolved outcomes. Follow its displayed action rather than treating every HTTP conflict identically.
Example: Nadia confirms GBP 250 and loses the response. Replaying the original intent resolves that posting. Creating a fresh draft or regenerating a new-key post is not a reliable retry strategy.
These stored-intent guarantees apply to the implemented donation workflows. Do not assume sponsorship creation or update commands use the same mechanism: after an uncertain sponsorship response, reload/search its state before retrying.