fix(frontend): submit Vercel drain grace period

[abcxff]

Summary

• include drainGracePeriod when creating serverless runner configs through the legacy-compatible payload branch
• share Vercel's 295-second request lifespan and validate drain grace periods below it
• default Vercel drain grace periods to 5 seconds in both standard and quick setup flows

Root cause

New runner configs have no existing protocolVersion, so the frontend selected the legacy-compatible payload branch. That branch omitted drainGracePeriod, causing the API to apply its 1800-second fallback, which is invalid for Vercel's 295-second request lifespan.

Verification

• pnpm --filter @rivetkit/engine-frontend check-types
• pnpm --filter @rivetkit/engine-frontend test (31 tests)
• pnpm --filter @rivetkit/engine-frontend build
• git diff --check

[railway-app]

🚅 Deployed to the rivet-pr-5517 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
frontend-cloud	😴 Sleeping (View Logs)	Web	Jul 30, 2026 at 10:19 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Jul 30, 2026 at 10:19 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Jul 30, 2026 at 10:19 pm
website	😴 Sleeping (View Logs)	Web	Jul 30, 2026 at 10:17 pm
ladle	✅ Success (View Logs)	Web	Jul 30, 2026 at 10:11 pm
mcp-hub	✅ Success (View Logs)	Web	Jul 30, 2026 at 10:09 pm

[claude]

Review

Scoped, well-targeted fix. The root cause tracks: the legacy-compatible payload branch in buildServerlessConfig omitted drainGracePeriod, so the API applied its 1800s fallback, which exceeded Vercel's ~295s request lifespan and got rejected by the drain_grace_period >= request_lifespan check in engine/packages/pegboard/src/ops/runner_config/upsert.rs.

Verified correct:

• connect-manual-serverless-frame.tsx: adding drainGracePeriod: values.drainGracePeriod to the legacy branch matches the already-present handling in the new-protocol branch — good, this fixes the bug for all serverless providers, not just Vercel.
• New VERCEL_REQUEST_LIFESPAN - 1 max bound in connect-vercel-form.tsx lines up with the backend's strict < check (drain_grace_period >= request_lifespan is rejected), so the frontend validation won't let users submit a value the backend would reject.
• Default of 5s is well under the default actor_stop_threshold (1800s), so no conflict with the other backend check.
• Deduplicating VERCEL_REQUEST_LIFESPAN/VERCEL_DRAIN_GRACE_PERIOD/configurationSchema into connect-vercel-form.tsx and re-exporting from connect-quick-vercel-form.tsx is a nice cleanup — previously the quick-connect flow hardcoded requestLifespan: VERCEL_SERVERLESS_MAX_DURATION - 5 and drainGracePeriod: 0 separately, which is exactly how they could drift out of sync with the full Vercel flow.
• No stale references to the removed VERCEL_SERVERLESS_MAX_DURATION export from connect-vercel-frame.tsx remain elsewhere.

Suggestion (test coverage):
The bug was a missing field in one branch of buildServerlessConfig, and the fix is a one-line addition — exactly the kind of regression a quick unit test would catch if it's ever dropped again (e.g. when a third payload branch is added). Given CLAUDE.md's emphasis on regression tests for bug fixes, consider adding a small test that asserts buildServerlessConfig includes drainGracePeriod in the legacy-branch payload, and/or a schema test asserting connect-vercel-form's configurationSchema rejects drainGracePeriod >= VERCEL_REQUEST_LIFESPAN and defaults to 5. The PR description mentions 31 existing tests pass, but none appear to target this file/behavior directly.

Minor/non-blocking:

• drainGracePeriod now has its default declared twice — once in the zod schema (.default(VERCEL_DRAIN_GRACE_PERIOD)) and again explicitly in each frame's RHF defaultValues. Not a bug (both reference the same constant), but worth a short comment noting why both are needed (zod default covers parse-time fallback if the field is ever omitted; RHF default seeds the input's displayed value).

Overall this looks correct and safe to merge; the test-coverage point is the only thing I'd push on.