Practical decision guide
5 min read
Updated
Confirm an action without duplicate submissions
Choose inline status, Toast or a result page and recover from slow or uncertain writes.
Direct answer
Tie feedback to the operation: starting, accepted, completed, rejected or outcome unknown. Prevent accidental duplicate submission while preserving recovery. A Toast can supplement a durable result, but must not be the only evidence of an important save or the only place to resolve an error.
01
Define completion evidence
For an export, a job identifier means queued, not file ready. For a save, receiving a request may precede persistence. Name the evidence needed before announcing completion.
Keep status near the action. Use a result page for a durable reference and next steps. A Toast is supplementary feedback that can safely be missed, not the only record of a consequential result.
- confirm save without duplicate requests
- toast or permanent success message
For an export, a job identifier means queued, not file ready. For a save, receiving a request may precede persistence. Name the evidence needed before announcing completion. Keep status near the action. Use a result page for a durable reference and next steps. A Toast is supplementary feedback that can safely be missed, not the only record of a consequential result.
02
Prevent duplicate work
A pending button reduces repeated clicks but does not guarantee server deduplication. Define how the application identifies the same operation and retrieves its result before adding automatic retries.
Consider multiple tabs and a connection lost after acceptance. Keep independent fields usable when safe. Explain the wait instead of making the action disappear.
A pending button reduces repeated clicks but does not guarantee server deduplication. Define how the application identifies the same operation and retrieves its result before adding automatic retries. Consider multiple tabs and a connection lost after acceptance. Keep independent fields usable when safe. Explain the wait instead of making the action disappear.
03
Example: prepare a report
Show Request accepted with the service’s reference. Say Report ready only after the artifact exists. Keep its download link in the report list after temporary feedback closes.
After a lost response, show Result not confirmed and inspect that request before creating another. If lookup is unsupported, state the uncertainty instead of offering a possibly duplicate write.
Show Request accepted with the service’s reference. Say Report ready only after the artifact exists. Keep its download link in the report list after temporary feedback closes. After a lost response, show Result not confirmed and inspect that request before creating another. If lookup is unsupported, state the uncertainty instead of offering a possibly duplicate write.
04
Keep recovery accessible
Validation errors preserve valid input and identify corrections. Service failures retain context. Expired authentication returns to the same task after sign-in without claiming the original operation failed for certain.
Announce updates without unnecessary focus movement. Avoid duplicate announcements from both focus and live regions. Keep the recovery action available after a notification disappears.
Validation errors preserve valid input and identify corrections. Service failures retain context. Expired authentication returns to the same task after sign-in without claiming the original operation failed for certain. Announce updates without unnecessary focus movement. Avoid duplicate announcements from both focus and live regions. Keep the recovery action available after a notification disappears.
05
Test uncertainty
Exercise slow acceptance, rejection and a lost response after acceptance. Count actual operations rather than clicks. Verify that retry follows the service contract and never upgrades uncertainty into success.
This is not a payment or distributed-systems implementation. Confirm deduplication and reconciliation with the service owner before applying the pattern to irreversible or costly work.
Exercise slow acceptance, rejection and a lost response after acceptance. Count actual operations rather than clicks. Verify that retry follows the service contract and never upgrades uncertainty into success. This is not a payment or distributed-systems implementation. Confirm deduplication and reconciliation with the service owner before applying the pattern to irreversible or costly work.
Keep this
Verify in your product
- 01Acceptance differs from completion.
- 02Repeated clicks do not duplicate work.
- 03Unknown outcomes remain explicit.
- 04Important results remain readable.
- 05Failures retain useful input.
- 06Retry follows the actual contract.
Primary sources
Technical claims in this guide connect to first-party specifications and documentation.
- User notifications (opens in a new tab)W3C WAI · Primary reference for the documented mechanism. The worked scenario and decision checklist are original SkillCodex editorial guidance, not a certified implementation.
- Understanding status messages (opens in a new tab)W3C WAI · Primary reference for the documented mechanism. The worked scenario and decision checklist are original SkillCodex editorial guidance, not a certified implementation.
Continue
Related guides and tools
Understand → Recognize → Choose → Compare
Pack for your agent
Pre-written instruction by SkillCodex — your request is neither sent nor used to adapt this text; no content is generated, and copying executes nothing.
Implement correctly
Apply “Confirm an action without duplicate submissions” step by step
# Apply the “Confirm an action without duplicate submissions” guide in your agent ## Objective Tie feedback to the operation: starting, accepted, completed, rejected or outcome unknown. Prevent accidental duplicate submission while preserving recovery. A Toast can supplement a durable result, but must not be the only evidence of an important save or the only place to resolve an error. ## Prerequisites - Inspect the repository, documentation, and existing conventions. - Confirm the need matches the guide scope: Choose inline status, Toast or a result page and recover from slow or uncertain writes. - Preserve the correct decisions already in place. ## Guide steps - 1. Define completion evidence — For an export, a job identifier means queued, not file ready. For a save, receiving a request may precede persistence. Name the evidence needed before announcing completion. Keep status near the action. Use a result page for a durable reference and next steps. A Toast is supplementary feedback that can safely be missed, not the only record of a consequential result. - 2. Prevent duplicate work — A pending button reduces repeated clicks but does not guarantee server deduplication. Define how the application identifies the same operation and retrieves its result before adding automatic retries. Consider multiple tabs and a connection lost after acceptance. Keep independent fields usable when safe. Explain the wait instead of making the action disappear. - 3. Example: prepare a report — Show Request accepted with the service’s reference. Say Report ready only after the artifact exists. Keep its download link in the report list after temporary feedback closes. After a lost response, show Result not confirmed and inspect that request before creating another. If lookup is unsupported, state the uncertainty instead of offering a possibly duplicate write. - 4. Keep recovery accessible — Validation errors preserve valid input and identify corrections. Service failures retain context. Expired authentication returns to the same task after sign-in without claiming the original operation failed for certain. Announce updates without unnecessary focus movement. Avoid duplicate announcements from both focus and live regions. Keep the recovery action available after a notification disappears. - 5. Test uncertainty — Exercise slow acceptance, rejection and a lost response after acceptance. Count actual operations rather than clicks. Verify that retry follows the service contract and never upgrades uncertainty into success. This is not a payment or distributed-systems implementation. Confirm deduplication and reconciliation with the service owner before applying the pattern to irreversible or costly work. ## Acceptance criteria — Verify in your product - Acceptance differs from completion. - Repeated clicks do not duplicate work. - Unknown outcomes remain explicit. - Important results remain readable. - Failures retain useful input. - Retry follows the actual contract. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The steps come from a published, sourced guide, not improvisation.
- The checklist turns advice into verifiable criteria.
- The declared scope keeps the guide within its evidence.
Try next
Anchor the guide in the project
# Anchor the guide in the project ## Objective Turn the applied steps into durable repository conventions. ## Checks - Link each decision made to the guide step that justifies it. - Add the checklist to the relevant reviews. - Record out-of-scope cases for the neighboring guides. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:57a2fc72158ea09244a895ed86b6f1ee16c428f961251d222019fbd8ce8d5b20
Diagnose a problem
Diagnose a “Confirm an action without duplicate submissions” guide gap
# Diagnose a failed application of the “Confirm an action without duplicate submissions” guide ## Observed symptom [DESCRIBE THE SYMPTOM HERE] ## Observable checks - Replay the steps in order and note the first one that diverges: - 1. Define completion evidence — For an export, a job identifier means queued, not file ready. For a save, receiving a request may precede persistence. Name the evidence needed before announcing completion. Keep status near the action. Use a result page for a durable reference and next steps. A Toast is supplementary feedback that can safely be missed, not the only record of a consequential result. - 2. Prevent duplicate work — A pending button reduces repeated clicks but does not guarantee server deduplication. Define how the application identifies the same operation and retrieves its result before adding automatic retries. Consider multiple tabs and a connection lost after acceptance. Keep independent fields usable when safe. Explain the wait instead of making the action disappear. - 3. Example: prepare a report — Show Request accepted with the service’s reference. Say Report ready only after the artifact exists. Keep its download link in the report list after temporary feedback closes. After a lost response, show Result not confirmed and inspect that request before creating another. If lookup is unsupported, state the uncertainty instead of offering a possibly duplicate write. - 4. Keep recovery accessible — Validation errors preserve valid input and identify corrections. Service failures retain context. Expired authentication returns to the same task after sign-in without claiming the original operation failed for certain. Announce updates without unnecessary focus movement. Avoid duplicate announcements from both focus and live regions. Keep the recovery action available after a notification disappears. - 5. Test uncertainty — Exercise slow acceptance, rejection and a lost response after acceptance. Count actual operations rather than clicks. Verify that retry follows the service contract and never upgrades uncertainty into success. This is not a payment or distributed-systems implementation. Confirm deduplication and reconciliation with the service owner before applying the pattern to irreversible or costly work. ## Possible causes - A step was skipped or executed out of order. - The actual need falls outside the guide scope. - A checklist criterion was never verified. ## Bounded fixes - Redo only the diverging step and what depends on it. - Document the gap if the guide scope does not cover the need. ## Final verification — Verify in your product - Acceptance differs from completion. - Repeated clicks do not duplicate work. - Unknown outcomes remain explicit. - Important results remain readable. - Failures retain useful input. - Retry follows the actual contract. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
- Requires · The real project context: repository, documentation, and existing constraints
Why it works
- The diagnosis replays ordered steps instead of searching at random.
- Fixes stay bounded to the first real divergence.
- The checklist serves as a reproducible final verification.
Try next
Prevent the next drift
# Prevent the next drift ## Objective Turn the first diverging step into an explicit project check. ## Checks - Add a focused check on the step that diverged. - Verify the checklist on a second real case. - Document the scope limit you hit. ## Guardrails - Show the proposed changes before any external action. - Do not publish, send, delete, pay for, or change remote state without explicit authorization. - Preserve unrelated changes and stop if the scope becomes ambiguous. ## Output format - Outcome or verdict. - Files or actions involved. - Checks run and observable evidence. - Remaining blockers or limitations.
sha256:151f6c0dc828645ec6d47637add4d11fa2506c0ce3471f0cc410808179b82304
Pack digest: sha256:4656cf298567f0d20a828d6eecd91aed9aeb5428f8af95ab6072f694e88bdb12