[smilne3]

This finishes #139. When a change to a transaction was refused because the transaction had gone stale, the picker and the reimbursable controls said "Refresh and try again". The installed app has no refresh button. Now they show the latest themselves.

What changes for you

This only changes what you see when a change on Transactions is refused because the page is out of date:

What happened since the page loaded	Before	Now
The bank removed the transaction, as it does when a pending one posts	"Your bank removed that transaction. Refresh and try again."	the list reloads: the removed row goes, and the posted one shows, ready to pick again
The transaction is gone	"That transaction no longer exists. Refresh and try again."	the list reloads without it
The category was deleted, on the other phone say	"That category no longer exists. Refresh and try again."	"That category no longer exists. Showing the latest.", and the category list updates
The bank changed the transaction during the save	"This transaction just changed. Refresh and try again."	"This transaction just changed. Showing the latest.", and the list reloads

The reimbursable tick and editor, which already reloaded, say "Showing the latest." too. For a removed transaction they now reload as well, so one sheet no longer gives two answers.

Other refusals don't change. A credit-card payment, for example, still says why, and doesn't reload. Two people picking for the same transaction isn't one of these: the later pick simply wins, as before.

What's still missing: when the row itself is gone, its message goes with it, so nothing says the change wasn't saved. That was already true of the reimbursable controls. It's filed as #252, which suggests a notice above the list, like the one Goals has.

How

• components/CategoryPicker.tsx: after a refusal with status 404 or 409, it calls router.refresh(), as CategoryRulesCard and the reimbursable controls already do. Any other refusal still doesn't reload.
• app/api/transactions/categorize/route.ts:
  • The four stale-row refusals say "Showing the latest." instead of "Refresh and try again."
  • A removed transaction and a deleted category now answer 409 rather than 400, so the picker reloads for them.
  • Only the picker calls this route.
• app/api/reimbursable/route.ts: the same words for its three stale-row refusals. A removed transaction answers 409 rather than 400.

Checked

• New tests:
  • A 404 and a 409 each reload once and show the route's words.
  • A deleted category's message stays while the reload leaves the row as it was, and the options lose the category.
  • A 400, a 500 and a 503 don't reload.
  • Both routes answer each stale refusal with its status and words.
• Mutations: I broke each guard in turn (12 mutants), and tests caught all 12. They included:
  • no reload
  • a reload after only one of the two statuses, or after every refusal
  • a change from the server that keeps the message
  • each of the two routes' words and statuses put back
• Locally: vitest passes 2496/2496 in both time zones. tsc, lint, check:secrets, check:invariants and next build all pass.

Review

Code and behaviour: nothing Critical.

• It confirmed:
  • this route can't answer the environment guard's 409
  • nothing else reads these statuses
  • a name that never was a category can't come from the picker
  • two quick picks are safe
• Three Important findings:
  • A row that's gone takes its message with it. That's now A refused change to a transaction that's gone leaves no message once the list reloads #252, since the reimbursable controls do the same.
  • The words kept through the reload could outlast a later, unrelated change. I removed that mechanism. For this route a stale refusal almost never changes a row that stays on screen.
  • The reimbursable controls still said "Refresh and try again". Changed here.
• Not done: the category-rules design spec still quotes the old statuses and words. It's a dated record that later fixes haven't kept current either.

No phone check

None of these can be brought about on purpose without changing your real data. Deleting a category takes its rules with it, and the bank decides when a pending transaction posts. A preview won't help either: a pick there still saves to your real data, and only rule learning is off. The screens themselves don't change, so I'd merge this without a phone check.

Closes #139.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
every-dollar-counts	Ready	Preview	Nov 5, 2026 5:21pm UTC