Found by the weekly upstream compatibility check (session). Filing rather than PRing because widening this bound is a product decision plus non-trivial type work, not a mechanical bump.
Upstream change
@mastra/core latest is 1.63.2. packages/mastra/package.json declares "@mastra/core": ">=1.51.0 <1.52.0" and pins the dev dependency at 1.51.0, so the adapter is twelve minor lines behind and cannot be installed next to a current Mastra at all. packages/mastra/README.md states this deliberately ("Experimental non-streaming recording and replay support for Mastra 1.51.x", pnpm add @zenml-io/kitaru-mastra @mastra/core@1.51.0), so this is a known-narrow bound rather than an oversight.
Failing surface
With @mastra/core 1.63.2 and the peer bound temporarily widened:
- Runtime tests pass.
pnpm --filter @zenml-io/kitaru-mastra run test → 72 passed (9 files), and examples/typescript/mastra_support_triage → 31 passed. The recording/replay behavior the adapter implements still works.
- Typecheck fails.
pnpm --filter @zenml-io/kitaru-mastra run typecheck:
test/agent.test.ts(2,1): error TS2578: Unused '@ts-expect-error' directive.
test/compatibility/mastra-1.51.test.ts(3,1): error TS2578: Unused '@ts-expect-error' directive.
test/compatibility/mastra-1.51.test.ts(96,5): error TS2322: Type '(options: ModelCall) => Promise<ModelResult>'
is not assignable to type '(options: LanguageModelV2CallOptions) => PromiseLike<{ content: LanguageModelV2Content[]; ... }>'
Types of property 'content' are incompatible.
Type 'unknown[]' is not assignable to type 'LanguageModelV2Content[]'.
test/replay-safety.test.ts(7,1): error TS2578: Unused '@ts-expect-error' directive.
test/replay-safety.test.ts(66,5): error TS2322: (same shape)
Both classes of error are in the test harness, not src/:
- Mastra now ships declarations for the test helper the tests import, so the
@ts-expect-error suppressions above those imports are unused.
- Mastra's mock-model
doGenerate callback is now typed against LanguageModelV2CallOptions/LanguageModelV2Content, so the loosely typed ModelCall/ModelResult fixtures in test/helpers.ts no longer satisfy it.
Why this is not a mechanical bump
Green runtime tests at 1.63.2 are weak evidence here, because the tests were written against 1.51 semantics that the README documents as version-specific:
- Tool-node inputs are recorded as the raw model-requested arguments, on the stated assumption that "Mastra 1.51 exposes those same arguments to replay hooks and step results" and that schema defaults/coercion happen later inside tool execution.
structuredOutput.model is rejected before execution because "Mastra 1.51 does not expose" the internal second model call to the parent agent's public callbacks.
Twelve minor lines of Mastra could have changed either of those, and test/compatibility/mastra-1.51.test.ts only pins the 1.51 contract — nothing in the suite would notice if 1.6x now exposes the structured-output model call, or if it normalizes tool arguments before the replay hook sees them. Widening the bound without re-deriving those two behaviors risks silently recording or replaying the wrong thing.
Options
- Leave the bound at 1.51.x and say so louder. Zero risk, but the adapter is unusable for anyone on a current Mastra, and the gap grows weekly.
- Widen to
>=1.51.0 <1.64.0 and support both lines. Requires: retyping the test/helpers.ts mock fixtures against LanguageModelV2CallOptions/LanguageModelV2Content and dropping the now-unused @ts-expect-error directives; adding a test/compatibility/mastra-1.63.test.ts alongside the 1.51 file; and re-deriving the two README behaviors above against 1.63 (particularly whether structuredOutput.model is still invisible to parent callbacks — if it is now visible, the pre-execution rejection should become real support).
- Move support to 1.6x only and cut a new adapter major. Cheapest of the two "support current Mastra" paths, since it avoids a dual-line test matrix, but it strands existing 1.51 users.
Reproduction for either widening path:
cd packages/mastra
# set devDependency @mastra/core to 1.63.2 and peer bound to ">=1.51.0 <1.64.0"
pnpm install
pnpm --filter @zenml-io/kitaru-mastra run test # 72 passed
pnpm --filter @zenml-io/kitaru-mastra run typecheck # fails as above
Also worth deciding as part of this: whether examples/typescript/mastra_support_triage tracks the same bound (it pins @mastra/core 1.51.0 today and its 31 tests pass at 1.63.2).
Found by the weekly upstream compatibility check (session). Filing rather than PRing because widening this bound is a product decision plus non-trivial type work, not a mechanical bump.
Upstream change
@mastra/corelatest is 1.63.2.packages/mastra/package.jsondeclares"@mastra/core": ">=1.51.0 <1.52.0"and pins the dev dependency at1.51.0, so the adapter is twelve minor lines behind and cannot be installed next to a current Mastra at all.packages/mastra/README.mdstates this deliberately ("Experimental non-streaming recording and replay support for Mastra 1.51.x",pnpm add @zenml-io/kitaru-mastra @mastra/core@1.51.0), so this is a known-narrow bound rather than an oversight.Failing surface
With
@mastra/core1.63.2 and the peer bound temporarily widened:pnpm --filter @zenml-io/kitaru-mastra run test→ 72 passed (9 files), andexamples/typescript/mastra_support_triage→ 31 passed. The recording/replay behavior the adapter implements still works.pnpm --filter @zenml-io/kitaru-mastra run typecheck:Both classes of error are in the test harness, not
src/:@ts-expect-errorsuppressions above those imports are unused.doGeneratecallback is now typed againstLanguageModelV2CallOptions/LanguageModelV2Content, so the loosely typedModelCall/ModelResultfixtures intest/helpers.tsno longer satisfy it.Why this is not a mechanical bump
Green runtime tests at 1.63.2 are weak evidence here, because the tests were written against 1.51 semantics that the README documents as version-specific:
structuredOutput.modelis rejected before execution because "Mastra 1.51 does not expose" the internal second model call to the parent agent's public callbacks.Twelve minor lines of Mastra could have changed either of those, and
test/compatibility/mastra-1.51.test.tsonly pins the 1.51 contract — nothing in the suite would notice if 1.6x now exposes the structured-output model call, or if it normalizes tool arguments before the replay hook sees them. Widening the bound without re-deriving those two behaviors risks silently recording or replaying the wrong thing.Options
>=1.51.0 <1.64.0and support both lines. Requires: retyping thetest/helpers.tsmock fixtures againstLanguageModelV2CallOptions/LanguageModelV2Contentand dropping the now-unused@ts-expect-errordirectives; adding atest/compatibility/mastra-1.63.test.tsalongside the 1.51 file; and re-deriving the two README behaviors above against 1.63 (particularly whetherstructuredOutput.modelis still invisible to parent callbacks — if it is now visible, the pre-execution rejection should become real support).Reproduction for either widening path:
Also worth deciding as part of this: whether
examples/typescript/mastra_support_triagetracks the same bound (it pins@mastra/core1.51.0 today and its 31 tests pass at 1.63.2).