Rejected Remembered Value Blocks Recovery

What goes wrong

A remembered value (last location, cached token, saved input) is rejected by whoever consumes it, but is neither cleared nor replaced with a fresh one. Every attempt re-reads the same stale value and is rejected again; the user or flow cannot escape.

Example

An old organisation id sits in browser storage; the server rejects it as unauthorised, the app never clears it, and the user is stuck in a redirect loop.

Not to be confused with

The loop is the missing clear or re-fetch on rejection — not a saved batch checkpoint resumed after its context changed (Stale Resume Checkpoint) and not a cache never refreshed after a successful change (Missed Snapshot Refresh).

Discovered by

@sks24git GitHub

Field notes · 6

@sks24git2026-11-03

A saved code was cleared only when it worked, so a code that could never work stayed saved. It kept hiding every newer code for a month, the exact problem the change set out to end.

Clear saved input on any final answer, not only on success. A refusal is final too.

@sks24git2026-10-30beat 2 review rounds

A keep-alive loop got its own database link and learned to retry after errors, but it opened that link once and never again. After one server restart every retry hits the dead link, and the live job is swept.

Reopen the connection inside the retry, not before the loop. A retry on a dead handle only logs.
Open side resources inside the cleanup scope. A failed open must not skip the release.

@sks24git2026-10-25

A plan made recorded client runs a merge gate, while the only refresh of a stale recording was a failure on the main branch. An intended product change goes red on its pull request, main never fails, nothing renews.

Put the refresh path on the same side as the gate. A trigger that fires only after merge never fires when the gate blocks the merge.
Read the limits of a workflow before you borrow it.

@sks24git2026-09-10beat 9 review rounds

The stored location was validated for shape only, so a path naming a name the account no longer has is returned on every resume. The router rejects it and drops the user at the chooser again.

Validate a memory against today's identity, not only its syntax. A well-formed path can still point at somebody who is gone.

@sks24git2026-09-10beat 2 review rounds

The remembered location embeds the user's handle, and the handle can be changed at any time. After a rename the saved path is returned unchanged and sign-in resumes into a URL nobody owns.

Never persist a mutable identifier inside a stored path. Keep the id and rebuild the URL at the moment you use it.

@sks24git2026-09-10

A passive effect stored another account's deep link as the active account's last place, and the new redirect leaves without marking that place rejected. The saved value keeps sending the user back.

A rejected destination must be recorded as rejected, not merely abandoned. Otherwise the memory of it outlives the redirect.