fix(config): reject invalid action body limits - #2807
Open
Boyeep wants to merge 3 commits into
Open
Conversation
commit: |
Contributor
Performance benchmarksCompared 0 improved · 0 regressed · 6 within ±1.5%
View detailed results and traces 🟢 improvement · 🔴 regression · ⚫ change below 1.5% · paired base/head |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
experimental.serverActions.bodySizeLimitvalues during config resolution instead of silently substituting 1 MBbytes.parse()grammar and fallback exactly, including explicit+signs and its unusualparseIntfallbackUser impact and reproduction
With:
Next.js refuses to start or build. Vinext previously warned, silently changed the value to 1 MB, and continued. That hides configuration mistakes until a Server Action later fails at a limit the developer never selected. Negative strings behaved the same way, negative numbers used a vinext-specific error, and wrong-type values were treated as omitted.
Strict parity also matters for accepted strings. Next's vendored parser accepts
"+2mb", but for strings outside its complete filesize grammar it falls back toparseInt(value, 10): for example,"2wat"is 2 bytes,"1e3"is 1 byte, and"1mb "is 1 byte. This PR preserves those surprising but authoritative semantics instead of inventing stricter validation.Expected Next.js behavior
Next validates
bodySizeLimitduring config resolution. Numbers pass through directly; strings go through its vendoredbytes.parse(); null,NaN, and results below one byte throw the canonical config error.Execution paths
resolveNextConfigis the shared configuration boundary for:Server Actions are an App Router feature; Pages paths do not consume the runtime action limit, but they share the same config validation just as Next validates the option globally.
Tests and verification
Tests were added first. The fallback-parity test failed against the previous implementation (
"1mb "returned 1 MiB rather than 1 byte), then passed after the parser change.Coverage includes malformed/negative strings, zero/
NaN, wrong types, omitted defaults, valid numeric and unit values,+2mb, and fallback cases"1mb "," 1mb", tab-separated units,"2wat","1e3", and"1.5".pnpm test tests/next-config.test.ts— 223 passedpnpm exec vp check packages/vinext/src/config/next-config.ts tests/next-config.test.ts— passedpnpm run build— passed (only the repository's expected virtual-module external warnings)Self-review
Automated review correctly identified missing explicit-positive-sign support; commit
debb4e1aadded it. The final review then found a broader issue: the hand-written parser was still stricter than Next's vendored parser. Commit004f4aa0replaces it with the same grammar, unit multipliers, flooring, andparseIntfallback while keeping valid error cases strict.I also tested removing the apparent duplicate type guard in config resolution. It is retained because it narrows the original value before preserving the runtime error label, avoiding an unsafe cast or object stringification.