---
title: "Verify cancelled requests cannot overwrite new navigation"
description: "Use an externally delayed sandbox detail response to check that leaving a page prevents late data from replacing the currently selected record."
canonical_url: "https://vostride.com/agent-library/network-recovery/cancel-pending-request.md"
md_url: "https://vostride.com/agent-library/network-recovery/cancel-pending-request.md"
content_kind: "recipe"
topic: "network-recovery"
---

# Verify cancelled requests cannot overwrite new navigation

Use an externally delayed sandbox detail response to check that leaving a page prevents late data from replacing the currently selected record.

## Risk

Cancellation is often advisory at the transport layer. The application must also reject stale response ownership so a delayed record cannot appear in the new page or leak through an old modal.

## Fixtures

- An owned sandbox record browser with two records A and B containing different identifiers, labels, and private notes.
- An external response fixture that delays only detail A while allowing detail B to complete immediately. Its trace distinguishes a confirmed client cancellation from a response delivered after B became visible.
- A test account authorized for both harmless records and an independent manifest describing each detail response exactly.

## Steps

1. Open record A from the list and verify the loading surface appears while the external fixture confirms A response is held.
2. Return to the list before A completes, open B, and verify B identifier, label, and note are visible.
3. Release the held A response externally if the request is still active, or record a confirmed cancellation from the external trace. Verify the current detail remains B with no A note, modal, or title inserted after that checkpoint.
4. Use the current detail breadcrumb to return to the list and verify navigation history still corresponds to B rather than resurrected A.
5. Reopen B and compare its displayed values with the independent manifest. Retain the trace proving either that A was cancelled or that its response was delivered only after B was visible; a permanently held request is not a completed check.

## Expected results

- The trace identifies which path was exercised: confirmed cancellation, or late response delivery after B became active.
- B retains exclusive ownership of the visible detail and breadcrumb state.
- No stale A content appears after response release or subsequent navigation.

## False-pass traps

- Two records with identical labels can make cross-record replacement invisible.
- Stopping before cancellation is confirmed or the held response is released leaves the race unresolved. A confirmed abort verifies cancellation behavior but does not independently test the late-response handler; report that distinction.

## Cleanup

- Release all held responses and remove the external delay rule.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa first test](/docs/agent-qa/guides/first-test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)

- [Network recovery QA recipes](/agent-library/network-recovery.md)
- [Software factory QA library](/agent-library.md)