feat: update mastra ai sdk#81
Conversation
|
Hey @caiopizzol, thanks for starting this! Can you resolve conflicts first before review? Also were able to test any of the tools through the mastra adapter; if so can you document it in the pr? |
Added tests + checked e2e exec @dionlow GTG |
- Add `types: ["node"]` to tsconfig to prevent auto-loading @types/bun - Add `as any` to remaining inputSchema props in aisdk.ts to avoid deep generic instantiation with ai SDK v6's tool() function
- Add pnpm.overrides to force all packages to use zod v4, eliminating the duplicate zod v3 compat type tree that was doubling memory usage - Remove @types/bun from sdk devDeps (only needed by Bun runtime, not tsc)
ToolExecutionContext.requestContext changed from Map<string, unknown> to RequestContext<unknown> in v1.0. Remove explicit type annotations and let TypeScript infer from createTool's generic.
…mports Rollup exact string matching doesn't match subpath imports like @mastra/core/tools or @modelcontextprotocol/sdk/server/index.js. Use regex patterns to match all subpaths.
|
looking now |
dionlow
left a comment
dionlow
left a comment
There was a problem hiding this comment.
Overall the update is pretty solid.
Two things to address
-
providerWorkspaceRefis missing from the mastra startOAuth tool (sdk/lib/adapters/mastra.ts:255). A consumer using the mastra adapter can't trigger OAuth for providers that require a workspace ref (e.g., Salesforce subdomains) — it'll silently be ignored even though the schema accepts it. -
Integration tests for the mastra adapter only execute startOAuth — the other 7 tools only have structural checks (correct id, schema references), but would be good to add the one more execute test as well to validate that credentials from requestContext actually flow through to the API calls. The mock handlers in sdk/test/mocks/handlers.ts seem to support and aren't wired up in the mastra test file. (can be followup).
- fix .args to .input for AI SDK v6 tool calls in example - add providerWorkspaceRef support to mastra startOAuth - extract resolveCredentials helper for consistent fallback logic - add comment explaining as any casts on inputSchema
Wire all 3 integration tests through setupMocks() and shared handlers instead of defining inline handlers and lifecycle hooks.
Verify requestContext > env vars > input params credential resolution, and test createRecord/sendRequest execute paths through MSW.
| export const sendReadRequest = tool({ | ||
| description: sendReadRequestToolDescription, | ||
| inputSchema: sendReadRequestInputSchema, | ||
| inputSchema: sendReadRequestInputSchema as any, |
There was a problem hiding this comment.
non-blocking / can be followup.
[sdk/lib/adapters/aisdk.ts:128,220,259] as any casts on inputSchema for checkConnection, sendRequest, and sendReadRequest suppress type checking between Zod v4 schemas and AI SDK v6's expected types.
If the schemas drift, runtime errors won't be caught at compile time.
suggestion: consider a typed adapter function (e.g. toAISDKSchema(schema)) that narrows the as any to a single location, or add a unit test that round-trips each cast schema through AI SDK's validation to catch drift early.
dionlow
left a comment
dionlow
left a comment
There was a problem hiding this comment.
Changes look solid, added a minor suggestion as followup. Thanks Caio!
3 participants
Added a proper test suite for the AI SDK v5 / Mastra upgrade. We had zero tests for the Mastra and MCP adapters, and the existing E2E tests require OpenAI credits to run.
Created 124 tests using Bun's test runner + MSW for HTTP mocking - no API calls needed, runs in ~600ms. Covers all three adapters: schema validation, tool structure,
requestContextinjection for Mastra, andMCPResponseformat for the MCP server.Run with
bun testfromsdk/. Unit tests intest/unit/, integration tests intest/integration/.