Aglet

How to verify stale-result prevention across request races

Verification must prove that a newer requested view is not overwritten by an older response and that valid historical results remain available when explicitly requested. Replay request races, record updates, refreshes, and errors, then inspect displayed versions and dependent writes.

Check whether the outcome improved

  1. Replay older and newer responses

    Issue an older delayed request followed by a newer fast request with distinct input or filter state. Confirm the final display belongs to the newest state and record the response order, identifiers, versions, and visible loading feedback. Repeat the order reversal to test both arrival sequences.

  2. Check source and refresh freshness

    Update representative data while a view loads, refresh the route, and compare source version, returned version, displayed version, and timestamp. Confirm cache or read-model behavior follows the intended freshness contract. Exercise empty, permission, and failure states without replacing them with old content.

  3. Exercise writes based on results

    Use the displayed result to open, assign, approve, or otherwise act where the workflow allows. Confirm the action checks current identity or version as required and does not silently apply an older view. Record conflict or refresh behavior and verify no duplicate action occurs.

What to carry forward

Classify freshness as protected, regressed, unchanged, or inconclusive with race, version, source, and dependent-action evidence attached. It passes only when the newest request wins, intentional historical views remain correct, and actions based on results cannot silently use obsolete state.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow