perf: construct the default Ajv engine lazily on first validation#2458
perf: construct the default Ajv engine lazily on first validation#2458felixweinberger wants to merge 1 commit into
Conversation
AjvJsonSchemaValidator built its Ajv2020 instance (plus ajv-formats registration) in the constructor. Client and Server construct the default validator unconditionally, so every embedding application paid several milliseconds of AJV instantiation at startup even when no JSON Schema validation ever runs - a tax on CLI cold start in particular. Defer engine creation to the first getValidator() call via a private lazy getter. A caller-supplied engine is still used as-is from construction, the 2020-12 dialect check still fires before any engine is built, and the public API is unchanged.
|
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/core
@modelcontextprotocol/server
@modelcontextprotocol/server-legacy
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — small, self-contained lazy-init refactor with test coverage and no public API change.
Extended reasoning...
Overview
The PR touches only packages/core-internal/src/validators/ajvProvider.ts plus a new test file. It defers construction of the default Ajv2020 + ajv-formats engine from the AjvJsonSchemaValidator constructor to the first getValidator() call via a private ??= lazy getter. All three usage sites (getSchema/compile and errorsText in the returned closure) were updated consistently to the memoized engine reference, and the caller-supplied-engine path (_userAjv) is untouched.
Security risks
None. No input handling, auth, or protocol behavior changes; the validation semantics (dialect check ordering, compile/getSchema logic, error text) are identical, only the timing of engine construction moves.
Level of scrutiny
Moderate-low. The validator is on a correctness-relevant path (tool output / elicitation schema validation), but the diff is a mechanical eager→lazy conversion of a single private field with no branching changes. getValidator() is synchronous, so there is no re-entrancy or race concern with the memoization. The only observable behavior shift is that a hypothetical Ajv construction failure would now surface at first validation instead of at provider construction, which is acceptable and matches the stated intent.
Other factors
Four new vitest cases cover lazy construction, memoization, dialect-check-before-construction ordering, and the caller-supplied-engine path. The tests peek at the private _ajv slot via a cast, which is a mild style nit but pragmatic. The changeset-bot has already flagged the missing changeset (a patch changeset for the affected published packages would be reasonable since the validator is bundled into client/server), so that decision is visible to the author and maintainers without further comment.
1 participant
Constructs the default Ajv engine lazily on first
getValidator()call instead of in the provider constructor.Motivation and Context
ClientandServerconstruct the default JSON Schema validator unconditionally, which builds Ajv2020 + ajv-formats at startup even for applications that never validate a JSON Schema. For CLI-style embedders this is measurable dead weight on every cold start. Deferring the engine build to first use removes it; apps that do validate pay the same cost, just at first validation.How Has This Been Tested?
4 new unit tests (lazy construction, memoization, dialect check ordering, caller-supplied engine unchanged). Full workspace suite green.
Breaking Changes
None — public API identical; the dialect check still precedes engine construction.
Types of changes
Checklist