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 26, 2026 at 3:31 pm
website	❌ Build Failed (View Logs)	Web	Aug 25, 2026 at 7:27 pm
kitchen-sink	😴 Sleeping (View Logs)	Web	Aug 25, 2026 at 5:54 pm
frontend-inspector	😴 Sleeping (View Logs)	Web	Aug 25, 2026 at 5:26 pm
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]

Code Review

Reviewed the diff for fix(frontend): submit Vercel drain grace period. This is a small, well-scoped fix. Summary of what it does:

• Adds drainGracePeriod to the legacy (protocolVersion == null) branch of buildServerlessConfig in connect-manual-serverless-frame.tsx, which previously silently dropped the user-entered grace period for old-style runner configs. This looks like the core bug fix.
• Moves VERCEL_SERVERLESS_MAX_DURATION (and derives VERCEL_REQUEST_LIFESPAN / new VERCEL_DRAIN_GRACE_PERIOD) into connect-vercel-form.tsx, and defines a Vercel-specific configurationSchema there that clamps drainGracePeriod to < VERCEL_REQUEST_LIFESPAN.
• Fixes an inconsistency where connect-vercel-form.tsx's own stepper schema (the full onboarding flow) and connect-quick-vercel-form.tsx (the quick-connect flow) were previously using the base manual-serverless configurationSchema (no drain-period/lifespan relationship enforced) instead of the new Vercel-aware one. Both now share the same validated schema via ConnectVercelForm.configurationSchema.
• Changes the Vercel dialogs' default drainGracePeriod from 0 to 5, matching the new VERCEL_DRAIN_GRACE_PERIOD constant used by the schema default, so the displayed default and the submitted default stay in sync.

Observations

• Correctness: The change set looks internally consistent — the max(VERCEL_REQUEST_LIFESPAN - 1, ...) constraint is always paired with the same VERCEL_REQUEST_LIFESPAN value used for the hardcoded requestLifespan at submit time, so the "grace period must be less than request lifespan" invariant holds for both the quick and full Vercel flows.
• Minor nit: the <Input type="number"> rendered by DrainGracePeriod (connect-manual-serverless-form.tsx) only sets min={0} and has no max, so out-of-range values are only caught by Zod on submit rather than being clamped/hinted in the browser control. Not a blocker since the schema still validates it, just a small UX polish opportunity.
• Duplication: connect-quick-vercel-form.tsx re-exports VERCEL_REQUEST_LIFESPAN/VERCEL_DRAIN_GRACE_PERIOD from connect-vercel-form.tsx purely so callers can keep referencing ConnectVercelForm.XXX regardless of which module they imported as ConnectVercelForm. A little redundant but harmless and keeps the call sites uniform.
• Test coverage: No automated tests are touched or added, consistent with this area of the codebase (form/dialog logic here isn't covered by existing unit tests, and per frontend/CLAUDE.md a Ladle story isn't a good fit since this flow depends on the data-provider/mutation stack). Given this changes default field values and adds a new validation boundary, it'd be worth a quick manual pass through both the "quick" and "full" Vercel connect dialogs in the browser (per the repo's frontend visual-change guidance) to confirm the Advanced/drain-grace-period field renders and validates as expected before merge.
• No security, performance, or naming/style issues found; the change follows existing patterns in the file (e.g., the .optional().default(...) style already used in the base schema).

Overall this looks like a solid, correctly scoped fix. (Re-verified against the latest commit; no changes since the last review pass.)