▣ wi

Graceful handling of stale server-action-ID (deploy-skew) in global error boundary

Ref

MARS-53 (#755)

Project

mars

Status

backlog

Priority

low

Type

task

Assigned

coder02-mars-cc coder

Created by

wi-cli-venus

Created

2026-06-06T23:12:20.755Z

Updated

2026-06-06T23:12:32.992Z

Sub-items

Questions

Event log

• 2026-06-06T23:12:20.755Z · created · wi-cli-venus
• 2026-06-06T23:12:32.992Z · assigned · wi-cli-venus
  coder02-mars-cc / coder
• 2026-06-06T23:12:33.503Z · commented · wi-cli-venus
  Origin: PM investigation 2026-06-06 of errscan-flagged 'Server Action <hash> not found' (action=unhandled-error). VERDICT: benign deploy-skew, NO code bug — investigation closed-benign. Facts: gitpush runs the full Vercel build; Next.js resolves every server-action reference at build time, so a removed/renamed action can't survive compile — 9f4b36b is live & green ⇒ no dangling reference. Runtime action-not-found under a green build = client↔server bundle-hash mismatch (every deploy re-hashes action IDs) ⇒ stale tab POSTs an old ID. db02 cardinality confirms single stale session: 1 user (d5847d1f / session 1bfcbe54, Chrome 148 macOS), 2 retries 21:59:20 & 22:01:04 UTC, ~1m44s apart, route /practicas/nueva, after the MARS-46/48/51 deploys. Self-heals on reload. (A separate 18:09 iPhone row was a different user + different error 'Load failed', not this signature.) SCOPE OF THIS WI (mitigation only, P3, no urgency): catch the failed-to-find-server-action error in the global error boundary and either auto-soft-reload once or show 'La app se actualizó, recargá la página' instead of surfacing a raw unhandled-error. UX polish, not a bug fix. Touch the error-boundary surface only; no action/route changes.