Vercel removed enableFunctionsExtendedMaxDuration everywhere: 20 breaking records from one flag
What changed
Between @vercel/sdk v1.27.0 and v1.28.0, the enableFunctionsExtendedMaxDuration project flag disappeared from the entire Vercel REST API surface in a single sweep. Not deprecated, not renamed — withdrawn. The flag appears 20 times in the v1.27.0 OpenAPI description and 0 times from v1.28.0 onward, with no successor field carrying equivalent semantics.
That one platform decision produced 20 distinct breaking-change records in the mendapi database, because the flag lived on many endpoints at once:
- 2 request-prop-removed:
PATCH /v9/projects/{idOrName}andPOST /v11/projectsno longer acceptresourceConfig.enableFunctionsExtendedMaxDurationin the request body - 16 response-prop-removed: the flag is gone from
resourceConfiganddefaultResourceConfigin responses acrossGET /v10/projects,GET /v9/projects/{idOrName},GET /v1/microfrontends/groups/{groupId}/projects,PATCH /v1/projects/{projectId}/microfrontends,PATCH /v9/projects/{idOrName},POST /v11/projects,POST /v1/projects/{idOrName}/avatar, and theGET /v3/eventspayload - 2 enum-value-removed: the
project-functions-extended-max-duration-updatedevent type was deleted fromGET /v1/events/typesandGET /v3/events
Who is affected
Three call-site patterns break, each in a different way:
- Writers. Project create and update schemas declare
additionalProperties: falseonresourceConfig, so a payload that still sends the flag is rejected outright — this is the loud failure. If your provisioning script sets extended function duration,PATCH /v9/projects/{idOrName}andPOST /v11/projectsstart returning errors after the spec change. - Readers. Code that reads
project.resourceConfig.enableFunctionsExtendedMaxDurationor thedefaultResourceConfigvariant now getsundefined. Nothing throws; a truthiness check silently takes the false branch. These are the quiet failures that survive deploys. - Event consumers. Handler branches keyed on
project-functions-extended-max-duration-updatedare now dead code. They never fire again, and no error tells you so.
One capability boundary worth stating plainly: whether extended function duration itself is still configurable is a platform-plan question outside code reach. A codemod restores request validity and removes dead reads; it cannot re-enable a capability the platform withdrew.
How to fix it
All 20 records are adjudicated code-fixable under one strategy — remove the discontinued field. The scanner tells you which of the three patterns your repo actually contains, file and line, without your code leaving your machine:
npx mendapi scan --repo .
The vercel-sdk migration packs draft the mend as a reviewable diff: delete the flag from request payloads, remove reads of both response paths, and clear single-line consumers of the removed event type. Flat destructuring bindings of resourceConfig are covered on the AST track:
npx mendapi fix --repo . --dry-run
Dry run is the default posture — you review a patch, your working tree stays untouched. The Vercel SDK migration guide documents each pack and its honest scope, and the Vercel tracker page carries every one of the 20 verdicts with its spec evidence.
Related
- vercel breaking-change guide — every tracked vercel entry on one page, with fixability verdicts.
- Vercel SDK v1.28 migration — the full migration guide with pack-backed fixes.
- 11 Vercel spec pairs: a real 12-endpoint removal, and the release notes that cried breaking — the long-form methodology report behind this provider's tracked changes.
- All monitored providers — live change counts for vercel and 19 others.
- Migration pack catalog — every deterministic fix mendapi ships.
- Getting started — scan your repo in 30 seconds, no code leaves your machine.