A feature PR that changed what over-long URLs return.
This is a real Veridu review of a real, merged pull request, shown as it came back. Nothing on this page is running — it is the stored result of one run against fastify/fastify#6716 (feat: add support of onMaxParamLength), reviewed on 2026-10-02.
Same diff, same instructions, run independently. Both reviewers completed. One found nothing to report; the other found three things, including the one below. That gap is the reason Veridu runs reviewers from multiple vendors instead of one.
Not blocked. Veridu blocks a merge only when both reviewers independently find the same defect and both rate it at or above your threshold. One reviewer's finding, however confident, goes to a human. A missed block still lands in front of someone; a wrong block gets in everyone's way.
maxParamLength overflow now always returns 414 instead of 404
Fastify now unconditionally registers a default `onMaxParamLength` handler (just like `onBadUrl`), so any request whose route param exceeds `maxParamLength` (default 100) gets a 414 JSON response instead of falling through to the configured not-found route/404 handler, even for apps that never opted into this feature.
- fastify.js:93 passes `onMaxParamLength` into processOptions, and processOptions (fastify.js:918-921) always includes it in `options.routerOptions` via buildRouterOptions, same pattern as the always-on `onBadUrl`.
- lib/route.js:680-684 `buildRouterOptions` sets `routerOptions[key] = options[key] ?? defaultOptions[key]` for every key in `routerKeys` (which now includes `onMaxParamLength`), so the default fastify.js handler is used whenever the user doesn't set `routerOptions.onMaxParamLength` themselves.
- test/router-options.test.js:71-87, 'Should honor maxParamLength option' constructs `Fastify({ maxParamLength: 10 })` (no onMaxParamLength configured anywhere) and the diff changes the expected status from `t.assert.strictEqual(resError.statusCode, 404)` to `414` — confirming this is the new default, not an opt-in.
- docs/Reference/Server.md:1010-1013 (unchanged by this diff) still states: 'If the maximum length limit is reached, the not found route will be invoked,' directly contradicting the new default 414 behavior.
The PR silently changes default behavior for every existing Fastify app: URL params exceeding maxParamLength used to be routed to the not-found handler (404), but now always get an unconditional 414 response, without any opt-in flag, and the unmodified docs still describe the old behavior.
We ran the same request against fastify before the merge and after it: a 150-character value on a /test/:id route, default maxParamLength.
The reviewer was right on the facts: the default changed for every app, custom not-found handlers are skipped for these requests, and the maxParamLength docs still say the not-found route is invoked. That is still true on fastify 5.12.5.
It was wrong to call it a regression. The 414 was requested in issue #6697 and shipped on purpose in v5.9.0. What the PR missed was the rest of the change: a note in the release, and the docs. That is a finding worth a human's minute, not a reason to block a merge — which is how Veridu treated it.
One pull request shows what a review looks like, not how often a second reviewer catches what the first one missed. For that, an independent run of four reviewers across 146 merged pull requests found 93.4% of issues caught by exactly one reviewer and none by all four, and concluded that a second reviewer is additive rather than duplicative. Different tools, different codebases — treat it as context, not as our result.
Public repos need only the PR URL and a free account. Private ones stay private — connect a repo, or run the CLI locally against your own API keys.
npm install -g veridu · veridu review <pr-url>