Aglet

Triage stale cached UI after a data change in a web app

Stale UI can come from browser or server cache, a delayed update, a missed partial replacement, or a second record being displayed. Start with the authoritative change and compare what the user sees after navigation, refresh, and a new session.

Establish what is happening

  1. Anchor the data change

    Record the record identity, old and new state, change time, action or source, and authoritative response. Use safe values and distinguish durable data from a display-only transition.

  2. Capture visible freshness

    Note page URL, selected filters or tabs, rendered status, last updated marker, request timing, and whether a normal reload or new session changes it. Record the first action that reveals stale content.

  3. Bound the consequence

    Describe whether users may repeat work, miss an incident, misunderstand approval, or only see a cosmetic delay. Separate stale content from a write that never persisted.

What to carry forward

Triage should state authoritative change, stale display, cache or refresh boundary, reproduction path, and user consequence. Escalate when stale status can drive a harmful decision; otherwise keep the freshness hypothesis open. Capture the authoritative change and the stale rendering separately, including navigation path, Turbo or full reload behavior, browser history, and the user decision affected.

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