Serverless After-Response Verdict

Decides whether work started AFTER the response will actually run. Pure function over how the handler is written and where it runs: no I/O, no dependencies.

THE MEASUREMENT. One Next.js 15.5.22 app, three routes, each logging BEFORE_RESPONSE and -- two seconds later -- AFTER_RESPONSE_COMPLETED. Run in TWO places: locally on next start, and DEPLOYED TO REAL VERCEL SERVERLESS (iad1), driven over HTTPS with the platform's own runtime logs read back.

LOCALLY, ALL THREE COMPLETE. THIS IS THE DECEPTIVE HALF. next start is one long-lived process; it never stops between requests, so a pending promise simply resolves. No local test can tell you otherwise.

ON THE REAL PLATFORM, THE WORK RUNS INSIDE THE NEXT, UNRELATED REQUEST:

    ### 22:20:53 GET /api/fireforget 200
        PROBE v1 fireforget BEFORE_RESPONSE

    ### 22:20:54 GET /api/waituntil 200
        PROBE v1 waituntil BEFORE_RESPONSE
        PROBE v1 waituntil REGISTERED
        PROBE v1 fireforget AFTER_RESPONSE_COMPLETED     <-- THE WRONG REQUEST
        PROBE v1 waituntil AFTER_RESPONSE_COMPLETED

The work DOES NOT VANISH. The environment is frozen at the response and thawed by the next request, which then carries it -- charged to that request's duration, bounded by its timeout, logged under its request id. Debugging it means finding a log line under a request that did not cause it.

WITH NO FOLLOWING REQUEST, IT NEVER RUNS AT ALL. Sixty seconds of silence against a two-second timer, and AFTER_RESPONSE_COMPLETED never appeared.

SO THE OUTCOME DEPENDS ON TRAFFIC. Busy endpoint: the work runs, late and misattributed. Quiet endpoint: lost. Same code, same deploy -- which is why it survives staging and fails at 3am. Every request in every run returned HTTP 200 and nothing errored anywhere.

IT STAYS QUIET WHERE IT SHOULD. Awaited work and waitUntil work both return WILL_RUN -- measured, both completed inside their own invocation on the real platform -- and neither even asks about the runtime, because that would be a question with no consequence. A long-lived process also returns WILL_RUN, honestly, but the reason says plainly that this is EXACTLY WHY the same code cannot be trusted on a frozen runtime.

THE REMEDY REFUSES THE FIX PEOPLE REACH FOR: await it, or hand it to the platform's keep-alive primitive. If it must not block the response AND must not be lost, put it on a queue -- the queue is durable across the freeze and the invocation is not. DO NOT reach for a longer timer; the environment is frozen, so a longer timer is just a longer wait for a thaw that may never come.

VERIFIED: 20 tests, measured by running the suite, every one of 8 mutations observed FAILING before restore.

DELIVERY: signed download of a hash-verified tarball, immediately on purchase. Permissive licence: unlimited products, unlimited clients, unlimited seats, no attribution, perpetual and irrevocable. One restriction, do not republish the source as source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function evaluateAfterResponseWork(site: HandlerSite): Verdict;

  export type Verdict = | { status: "WILL_RUN";