AskMeAnything
Ask
Ask
132
@peer_review_pat ·

"failed to find server action" errors for 20 minutes after every deploy Solved

Every deploy produces a Sentry spike: Failed to find Server Action "7f3a91c...". This request might be from an older or newer deployment. Between 30 and 60 of them, then it stops on its own. It is an internal dashboard so people leave a tab open from 09:00 and click save at 15:00. Nothing in our code changed between the deploys where it happens and the ones where it doesn't — it's purely a function of who had a tab open.

9 answers Share
Report

9 answers

BestTopNewOldControversial

Answering anonymously — a moderator will review it first.

  • @airflow_amir · 2w ago · 3 replies
    @airflow_amir ·

    Nothing is wrong with your code. Action IDs are hashes generated at build time and the server only knows the IDs from the build it is running. An old tab holds a bundle from build A and posts an ID that build B has never heard of, so the lookup fails. It stops after 20 minutes because that is how long it takes everyone to reload something.

    Three things help, in order of effort:

    • Deployment skew protection, if your platform has it: requests carrying the old build's id get routed to the old deployment, which is still running. This makes the problem disappear rather than get handled.
    • A version check. Serve the build id on every response (or poll a tiny /version route every 60s), compare to the one the page was served with, and show a "new version available — reload" bar. Cheap and it fixes the stale-JS-chunk 404s too.
    • Stop deploying at 15:00 on a workday. Only half a joke.

    What you cannot do is catch it and retry, because the client genuinely does not have code for the new action.

    140
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @ines_marchetti · last wk.
      @ines_marchetti ·

      The reload bar paid for itself the same week we shipped it — it also killed the recurring "the page looks broken" tickets that were actually stale chunk 404s after a deploy. One banner, two classes of bug.

      44
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
    • @peer_review_pat · last wk.
      @peer_review_pat OP ·

      Skew protection was one toggle and the banner took an afternoon. Next deploy produced 3 errors instead of 51, and those three were from a tab that had been open since Tuesday.

      18
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @capsule_curious · last wk.
    @capsule_curious ·

    In the meantime, degrade it properly. Wrap the action call, and if the message contains Failed to find Server Action, show your own dialog: "this page is out of date, reload to continue", with the form values preserved in state so the user doesn't retype anything. A 500 page for this is a terrible experience for something that is entirely your deploy's fault.

    62
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @layer_shift_lu · 2w ago · 2 replies
    @layer_shift_lu ·

    If you self-host this is worse than you think. Multiple containers behind a load balancer during a rolling deploy means some replicas are build A and some are build B, so you get this for as long as the rollout takes, and permanently if your build ids differ between replicas because each container built its own image.

    27
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @dockerfile_yuki · last wk.
      @dockerfile_yuki ·

      Set generateBuildId in next.config to the git sha so every replica of the same release agrees. That fixes the "same version, different ids" case. It does nothing for the cross-version case, which is the one OP has.

      21
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report
  • @leech_wrangler · 2w ago
    @leech_wrangler ·

    Same family as chunk load errors — the fix is the same fix. One header with the current build id on every response, a comparison in a small client hook, one banner. Do it once, it covers actions, chunks and any future "the client is old" failure.

    40
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
  • @mise_en_mess · 2w ago · 2 replies
    @mise_en_mess ·

    We moved every mutation to route handlers and the error went away. Actions are not worth this.

    9
    Share
    Reply

    Answering anonymously — a moderator will review it first.

    Report
    • @kitchen_table_talk · last wk.
      @kitchen_table_talk ·

      That does dodge this specific error, since a route URL is stable across builds. But the stale tab is still running old JS against a new API and will 404 on chunks the moment it navigates, so you need the reload path regardless. You traded a loud failure for a quiet one.

      7
      Share
      Reply

      Answering anonymously — a moderator will review it first.

      Report