fix(frontend): submit Vercel drain grace period

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5605 fix(workflow-engine): mark completed inner-loop iterations v …
• #5603 fix(rivetkit): expose engine ray IDs on errors for debug
• #5601 fix(frontend): submit Vercel drain grace period 👈
• #5604 fix(rivetkit-napi): remove stale HttpRequestBodyStream test …
• main

Get stack: forklift get 5601
Push local edits: forklift submit
Merge when ready: forklift merge 5601

_{change qnpvtqqz}

[railway-app]

🚅 Deployed to the actors-pr-5601 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
frontend-cloud	😴 Sleeping (View Logs)	Web	Aug 31, 2026 at 2:33 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Aug 31, 2026 at 4:36 am
website	❌ Build Failed (View Logs)	Web	Aug 31, 2026 at 1:40 am
frontend-inspector	😴 Sleeping (View Logs)	Web	Aug 29, 2026 at 10:38 am
ladle	✅ Success (View Logs)	Web	Aug 25, 2026 at 4:23 pm
mcp-hub	✅ Success (View Logs)	Web	Aug 25, 2026 at 4:23 pm

[claude]

Review: fix(frontend): submit Vercel drain grace period

Small, focused fix — the Vercel connect flow now submits drainGracePeriod/requestLifespan from validated schema constants instead of a hardcoded 0, and centralizes the Vercel-specific values (VERCEL_REQUEST_LIFESPAN, VERCEL_DRAIN_GRACE_PERIOD) in connect-vercel-form.tsx. Good use of a single source of truth shared between the "quick" and full Vercel connect frames.

Bug: the new drainGracePeriod < requestLifespan bound only applies to Vercel

connect-vercel-form.tsx builds a Vercel-specific configurationSchema that caps drainGracePeriod at VERCEL_REQUEST_LIFESPAN - 1:

drainGracePeriod: z.coerce
    .number()
    .min(0)
    .max(VERCEL_REQUEST_LIFESPAN - 1, `Must be less than ${VERCEL_REQUEST_LIFESPAN}`)
    ...

but the base configurationSchema in connect-manual-serverless-form.tsx (used directly by the generic/custom serverless flow in connect-manual-serverless-frame.tsx) still only has:

drainGracePeriod: z.coerce.number().min(0).optional().default(0),

with no upper bound relative to requestLifespan. Since both flows share the same DrainGracePeriod input component (no max attribute either), a user configuring a generic/custom serverless runner can still submit requestLifespan=10 with drainGracePeriod=1000 — the exact invariant this PR just added protection for on Vercel is left unenforced everywhere else. If this invariant matters generally (as the PR title/description implies), consider moving the drainGracePeriod <= requestLifespan check (e.g. via .refine() comparing both fields) into the base configurationSchema so all providers inherit it, rather than duplicating a Vercel-only ceiling.

Minor

• connect-manual-serverless-frame.tsx now passes drainGracePeriod: values.drainGracePeriod straight through to buildServerlessConfig without a fallback (unlike the ?? 1 / ?? 0 defaults on the neighboring fields). Since the base schema already .default(0)s the field via the RHF/zod resolver, this is likely fine, but worth double-checking that values.drainGracePeriod is never undefined at submit time for the generic flow — a stray undefined would previously have been silently coerced but now flows straight into the request payload.

Other

• No test coverage added, but this is a UI form-wiring fix with no complex logic, so that's reasonable to skip given the scope of the change.
• No security or performance concerns.

Overall a solid fix for the Vercel flow; the main follow-up worth considering is whether the new upper-bound validation should be generalized rather than Vercel-only.