Vercel waitUntil Drain Guard

Post-response work on Vercel, built around the fact that waitUntil is a lookup rather than a runtime primitive: the shipped implementation in @vercel/functions is getContext().waitUntil?.(promise), and getContext is globalThis[Symbol.for('@vercel/request-context')]?.get?.() ?? {}, so the optional chain turns a missing context into a silent no-op that returns undefined and leaves your promise floating, which is the exact failure waitUntil exists to prevent. That happens in every module-load drain loop, every cold-start listener, every unit test, and every self-hosted deployment, and nothing about it errors. This module reads the same symbol the SDK reads and exposes the answer as a boolean, then plans each task from the remaining duration budget rather than the configured maxDuration, since the docs state promises passed to waitUntil share the function's timeout and are cancelled when it expires with no failed invocation, no dead letter, and no retry. The planner returns one of three decisions: background it, await it inline when the context is not wired because latency is cheaper than a lost row, or refuse it outright when the work is must-not-lose or larger than the budget that is actually left. The self-check runs locally against a fake instance that installs the real symbol and models the freeze. Pinned to @vercel/[email protected].