Skip to content

eve-on-Vercel: source deploy 500s (ERR_MODULE_NOT_FOUND for internal #channel/*), and --prebuilt skips sandbox prewarm — no clean deploy for sandbox apps #556

Closed as not planned

Description

@davidstrouk

Link to a minimal reproduction

I don't have a standalone minimal repro repo yet — this was found on a real (private) production deployment, and I can't easily reproduce a fresh Vercel build outside that project right now. I'm filing anyway because the evidence points directly at eve's own source (see below), and I'm very happy to build and link a minimal repro (a tiny eve app with one sandbox-using subagent) if that helps you triage.

Steps to reproduce

  1. An eve app with at least one node/subagent that uses a sandbox (so eve provisions a Vercel Sandbox template).
  2. Deploy it to Vercel with a source vercel deploy (Vercel builds from source — the path eve's own warning recommends).
  3. Open any route of the resulting deployment (/, /eve/v1/slack, …).

Current vs. expected behavior

Current: every route returns HTTP 500 FUNCTION_INVOCATION_FAILED. The runtime logs show ERR_MODULE_NOT_FOUND for an eve-internal #channel/* import (e.g. #channel/compiled-channel). The generated Vercel function's dependency trace appears to drop eve's internal #… subpath files, so they're missing at runtime.

Expected: a source vercel deploy serves the routes normally (the internal #channel/* modules are included in the traced function bundle).

Why this matters (the bind): the two deploy paths are mutually exclusive and both break sandbox apps:

  • Source deploy (vercel deploy): eve does provision the Vercel Sandbox templates (the on-Vercel build runs prewarm, gated on VERCEL_DEPLOYMENT_ID) — build log shows eve: initialized N sandbox templates — but every route 500s from the trace gap above.
  • Prebuilt deploy (local vercel build + vercel deploy --prebuilt, with the traced output hand-patched to re-add the dropped #channel/* files): routes work, but the sandbox templates were never provisioned (a local build has no VERCEL_DEPLOYMENT_ID, so prewarm is skipped) → any agent that touches a sandbox throws SandboxTemplateNotProvisionedError at runtime.

So there's no single-command deploy for an eve app that uses sandboxes on Vercel. eve's own build even warns about the sandbox half:

Skipped Vercel sandbox template prewarm because VERCEL_DEPLOYMENT_ID is missing. The generated .vercel/output may reference sandbox templates that were not provisioned. Do not deploy it with vercel deploy --prebuilt; use vercel deploy so Vercel builds from source.

…but "use vercel deploy" is exactly the path that 500s from the trace gap.

eve version

0.19.0

Environment

  • Node.js 24 (both the local build and the on-Vercel build).
  • Vercel (Fluid Compute), deployed via the Vercel CLI.
  • Build via vercel build / vercel deploy with VERCEL_USE_EXPERIMENTAL_FRAMEWORKS=1.

Where does the bug occur?

At deploy/runtime on Vercel (a source vercel deploy's deployment). The build succeeds; the failure is at request time.

Deployment

A private production deployment (can share the deployment ID privately with the team to correlate platform-side logs).

Build and runtime logs

  • On-Vercel build (provisioning works): eve: initializing 6 sandbox templates … / eve: sandbox template "subagents/<id>" (vercel): preparing base runtime inside sandbox / eve: initialized 6 sandbox templates (0 reused, 6 built).
  • Source-deploy runtime: HTTP 500 FUNCTION_INVOCATION_FAILED on / and /eve/v1/slack, with ERR_MODULE_NOT_FOUND for an eve #channel/compiled-channel import.
  • Relevant eve source: the prewarm gate is dist/src/internal/nitro/host/vercel-build-prewarm.js → shouldPrewarmVercelBuild() (requires both VERCEL and VERCEL_DEPLOYMENT_ID).

Suggested direction

If eve's package exports (and/or the nitro tracing it emits) followed the internal #channel/* subpaths, a plain source vercel deploy would serve correctly and provision sandboxes in one step — removing the community --prebuilt + trace-patch workaround entirely. Happy to help test a fix or provide a minimal repro.

Activity

  1. ruiconti commented on Oct 14, 2026

    @ruiconti
    Contributor

    Closing as stale. This was reported on 0.18; the deploy and attachment provisioning paths involved have since been replaced (#3263, #4635), and it hasn't been reproduced on a current release.

    If this still happens on the current release (eve@0.79.1), please reopen with a reproduction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingbuildp1

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions