fix(frontend): submit Vercel drain grace period

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/actors

• #5593 fix(rivetkit-core): always signal actor stop handle on teard …
• #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 👈
• 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	Sep 1, 2026 at 8:23 pm
website	❌ Build Failed (View Logs)	Web	Aug 31, 2026 at 3:01 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Aug 31, 2026 at 4:36 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

Small, well-targeted fix. I traced the diff through buildServerlessConfig, the Vercel/quick-Vercel dialogs, and the backend's runner-config validation to check correctness.

What this actually fixes

The real bug is in frontend/src/app/dialogs/connect-manual-serverless-frame.tsx: buildServerlessConfig's legacy/deprecated branch (isNew === false, i.e. the existing runner config has no protocolVersion) built the RunnerConfigServerless object without drainGracePeriod at all, while the new-protocol branch already set it. Since this helper is shared by the Vercel, quick-Vercel, Railway, manual-serverless, and getting-started dialogs, any submission that hit the legacy branch silently dropped the user's chosen drain grace period. Adding drainGracePeriod: values.drainGracePeriod to that branch is correct and fixes the shared bug, not just Vercel.

Good catch: cross-field validation matches the backend invariant

The new .max(VERCEL_REQUEST_LIFESPAN - 1, ...) constraint on drainGracePeriod in connect-vercel-form.tsx mirrors engine/packages/pegboard/src/ops/runner_config/upsert.rs's server-side check that drain_grace_period < request_lifespan. Since Vercel's requestLifespan is a fixed constant (not user-editable), bounding the grace period client-side is the right call and avoids a round-trip validation error.

Minor observations (non-blocking)

1. Same numeric value, unrelated meanings — VERCEL_SERVERLESS_MAX_DURATION - 5 (safety margin subtracted from Vercel's hard timeout) and VERCEL_DRAIN_GRACE_PERIOD = 5 (default grace period) happen to both use 5, but they're independent constants. A short comment on VERCEL_DRAIN_GRACE_PERIOD (or a distinct value) would help a future reader avoid assuming they're linked.
2. Inconsistent guard elsewhere — Railway (connect-quick-railway-frame.tsx), the generic manual-serverless dialog, and getting-started.tsx all route through the same buildServerlessConfig/configurationSchema but still only have drainGracePeriod: z.coerce.number().min(0) with no upper bound tied to requestLifespan, and the general edit-shared-runner-config-form.tsx editor has no cross-field check either. Those flows can still submit drainGracePeriod >= requestLifespan and only fail server-side. Worth a follow-up to add the same max-relative-to-lifespan check there, since this PR establishes the pattern for Vercel.
3. Redundant re-export — connect-quick-vercel-form.tsx re-exports VERCEL_REQUEST_LIFESPAN/VERCEL_DRAIN_GRACE_PERIOD as aliases of ConnectVercelForm's constants, matching the file's existing "re-export everything from ConnectVercelForm" convention. Not wrong, just worth a second look at whether the indirection is needed since both call sites already import ConnectVercelForm directly.

Test coverage

No unit test covers the new .max() boundary on configurationSchema in isolation. Given this is a small zod-schema change with no new component, a Ladle story isn't warranted per this repo's guidance (would require mocking the datacenters data-provider stack), but a small schema-only unit test (parse drainGracePeriod = VERCEL_REQUEST_LIFESPAN - 1 succeeds, = VERCEL_REQUEST_LIFESPAN fails) would cheaply lock in the new invariant.

Security / performance

No concerns. This is client-side form/validation logic only; the authoritative check still lives server-side in pegboard's upsert.rs.