← All breaking-change reports

Vercel API breaking change: response-prop-removed on GET /v9/projects/{idOrName}

vercel · breaking · upstream source

What changed

According to the OpenAPI spec diff (vercel/vercel-oas-v1.27.0-to-v1.28.0), the following surface changed:

response-prop-removed: GET /v9/projects/{idOrName} -> 200 defaultResourceConfig.enableFunctionsExtendedMaxDuration

Who is affected

The enableFunctionsExtendedMaxDuration flag was removed from the entire Vercel project API surface in one sweep: it can no longer be sent in project create/update resourceConfig (schemas use additionalProperties:false, so continuing to send it is rejected), it is no longer returned in any project response, and the project-functions-extended-max-duration-updated event type no longer exists.

To find out whether your repo is hit — file and line number, no code leaving your machine:

npx mendapi scan --repo .

How to fix it

mendapi ships a deterministic migration pack for this change (vercel-project-extended-max-duration-removal). Preview the patch locally (dry-run is the default; nothing is modified without --apply):

npx mendapi fix --repo . --migration vercel-project-extended-max-duration-removal

The pack is idempotent, gold-regression tested, and safe on partially migrated code.

What the migration does:

The enableFunctionsExtendedMaxDuration flag was removed from the entire Vercel project API surface in one sweep: it can no longer be sent in project create/update resourceConfig (schemas use additionalProperties:false, so continuing to send it is rejected), it is no longer returned in any project response, and the project-functions-extended-max-duration-updated event type no longer exists. The mechanical fix is to delete the flag from request payloads, remove reads of resourceConfig.enableFunctionsExtendedMaxDuration / defaultResourceConfig.enableFunctionsExtendedMaxDuration from response handling, and delete event-handler branches keyed on the removed event type (those branches are now dead). Capability boundary: whether extended function duration itself is still configurable is a platform-plan question outside code reach; the codemod only restores request validity and removes dead reads, it cannot re-enable the capability if the platform withdrew it.

Before:

await client.patch(`/v9/projects/${id}`, { resourceConfig: { enableFunctionsExtendedMaxDuration: true } });
if (project.resourceConfig.enableFunctionsExtendedMaxDuration) enableLongTimeout();

After:

await client.patch(`/v9/projects/${id}`, { resourceConfig: {} });
// enableFunctionsExtendedMaxDuration withdrawn upstream (v1.28.0); flag and read removed.

Detected and tracked by mendapi — Dependabot for every API you depend on. Scans run locally; your code never leaves your machine.

Related

Pre-release. Change data is recorded from upstream provider releases, changelogs and OpenAPI spec diffs; every article links its source.