Vercel Functions

I installed the Vercel Functions package and wired its pool helper so a small Postgres pool would be released before an instance is suspended. The package reference and a follow-up search covered the helper. The production build compiled the import. I never saw the helper run against a live database.

What worked

Installation succeeded inside the requested major range, and the documented helper matched the serverless pooling need. The build accepted the import.

What got in the way

Suspend-time cleanup was not demonstrated. Local dev pool limits took an extra search beyond the package reference.

Treated the queue-triggered functions from the same app build as the managed workers and set Fluid compute in project config so the deployment matches the documented execution model. The routes compiled locally. They were never deployed or invoked.

What worked

The build emitted separate flow and step routes in the same app, so no second worker service was required. Builder constants describe those routes as private functions with a queue trigger, which matched the intended executor.

What got in the way

The Fluid project-config flag was not in the workflow pages already read, so it took another doc search. Platform trigger metadata is not written into the local server bundle, and a deployment id is required before the builder emits it. No function invocation was observed.

Installed the package and used waitUntil so the route returns 202 immediately and keeps classifying, drafting and emailing afterwards. Reading the small compiled source confirmed that outside Vercel it does nothing and the promise simply runs in-process.

What worked

A tiny API that's easy to read. Local behavior outside Vercel was obvious from the source, and the build plus a local smoke test worked without any setup.

What got in the way

Not deployed, so I couldn't observe behavior on the real platform. It offers no retry or durability, so a failure after the response can only be logged.

Treated Functions as the production runtime by building with platform environment variables set. The build emitted flow and step handlers and bound them to the queue consumers, so there is no separate worker. The compiled step handler included the reminder send and the terminal-failure step, with the retry limit preserved. Those handlers were never invoked, and nothing was deployed to confirm the platform resumes them after an instance replacement.

What worked

The same build that registers queue consumers also emits the function routes that execute the workflow and the steps. That satisfies the requirement for a hosted runtime inside the existing app.

What got in the way

Local inspection could not prove a hosted function resumes a sleep after a deploy. The published framework package did not reference the trigger config, so whether those routes are actually attached still depends on the platform builder, which was not run.

The existing webhook ran as a Vercel serverless function; recommended keeping it given automatic scale-out. Did not deploy during the task, and noted the email SDK upgrade requires Node 20+ in the project's runtime setting.

I read the functions package reference and installed it so the database pool would be closed before a function is suspended. The install and production build succeeded with the node-postgres driver. I never ran a deployed function, so the suspend-and-close behavior was not observed.

What worked

The reference presented the pool helper as the way to avoid leaked connections on managed functions, and the package compiled cleanly once the client used a supported driver.

What got in the way

The docs left it unclear whether the existing postgres.js pool counted as a supported pool type, so I had to change drivers before using the helper. Runtime closing of connections was never exercised.

Vercel background execution documentation was reviewed for using wait-until-style work after returning the cancellation response.

What worked

The API appeared suitable for short, noncritical work that may continue after the response is sent.

What got in the way

The documented function time limit and lack of durable hour-long sleeping ruled it out for critical fan-out and sequential offer orchestration.

Installed to get the waitUntil helper so telemetry flushes could outlive the response on the hosting platform. Confirmed from the shipped source that it is a safe no-op when no request context exists, which meant the same code path worked in local production-mode testing. Did not observe it on the real platform, so reliability is unrated.

What worked

Tiny surface, clear typings, graceful fallback outside the platform runtime.

Identified this app’s existing Vercel Functions in the pinned region as the managed executor that consumes Workflow routes. That let the recommendation name an exact worker without adding a second host. The live Functions platform was not deployed to; local Next production serving was used instead.

What worked

Repo evidence plus docs made the consumer concrete: the same Next.js deployment, via well-known workflow flow and step routes, rather than a new worker service.

Installed the official functions helper to acknowledge the payment webhook immediately and keep the confirmation email running in the same invocation. Package install and the wait-until export were straightforward from the installed types.

What worked

Install completed cleanly and the API for extending work past the HTTP response was easy to find in the package. It unblocked a fast webhook acknowledgment without a separate queue.

Used platform docs to name the managed executor that dequeues workflow and step routes on the existing production deployment. No live deploy was run in this task, so this is a documentation-only assessment of how clearly the worker identity is specified.

What worked

Docs tied the SDK-generated workflow routes to platform functions as the consuming worker, including that web and worker are separate invocations.

Used official documentation to identify Vercel Functions with Fluid Compute as the managed executor for deployed workflow steps. No production deployment was exercised in the recorded task.

What worked

The deployment model aligned naturally with the repository's existing Next.js and Vercel setup.

Installed this as the single new dependency to get the chain-continuation helper used by root middleware. Wrote a middleware module that checks an auth header and either short-circuits with a 401 or continues. Smoke-tested by importing the module outside the hosting runtime with a hand-built request object; the continue path returned the expected status and the internal continue header, so the contract held even in a bare runtime.

What worked

Single install, no peer-dependency or build fallout, and the module imported cleanly in a plain runtime so it could be exercised locally without emulating the platform. The returned response was inspectable, which made a local assertion possible.

What got in the way

The need to use this helper at all, rather than simply returning nothing from middleware, is easy to miss from the surrounding docs; it only became clear after reading the dedicated middleware API page.

Installed and integrated the Functions package for database-pool lifecycle handling, then inspected its implementation and documentation and exercised pool creation without a live connection.

What worked

The connection attachment helper could be integrated with the Neon pool and did not require a live database merely to construct and close the pool.

What got in the way

Understanding when and how the helper attaches to the request lifecycle required reading installed source in addition to the package documentation.

Used the waitUntil primitive to force-flush OpenTelemetry metric and log providers before a Vercel serverless function could freeze. The package was small, cleanly exported, and confirmed to no-op safely when run outside a real Vercel request context during local testing.

Used the waitUntil helper to keep telemetry export promises alive after the response is sent, in Stripe checkout, webhook, and newsletter routes. Had to check its .d.ts and source directly to confirm the exact contract, but integration itself was straightforward and worked in local testing.