Skip to content

25R2-0.50.0

Choose a tag to compare

@saratcvemuri saratcvemuri released this 29 Aug 01:05
· 10 commits to main since this release

Changed

  • Upgraded the agents SDK from 0.0.98 to 0.21.0, which carries the streamable-http transport rewrite that fixes concurrent-request response correlation. Under 0.0.98 two concurrent tool calls in one session could have their responses crossed — a run_inquiry for one GI returning another GI's rows, with the other call's topN — which is the silent-wrong-data failure class, indistinguishable from a legitimate result. 0.21.0 scopes request→stream mappings per connection, prefers the originating connection, and raises an explicit -32603 when two connections claim the same request id rather than silently crossing payloads.
    • @modelcontextprotocol/sdk (1.30.0) and zod (4.x) were transitive dependencies of agents 0.0.98 that this codebase imports directly; they are now required peers of agents and are pinned as explicit direct dependencies. @cloudflare/workers-types moves to v5 (required by partyserver 0.5.x and current wrangler).
  • The audit-log flush is scheduled through the Agent schedule() API instead of a raw DO alarm. Since 0.21.0 the base Agent class owns the DO's single alarm slot — its scheduler re-arms the alarm from its own schedule table and calls deleteAlarm() when nothing is due — so the previous ctx.storage.setAlarm() + alarm() override would have been silently cancelled (log batches dropped with no error) and would have shadowed the SDK's dispatcher. The buffer now arms this.schedule(seconds, "flushLogsScheduled"). Eviction-survival semantics are unchanged: the buffer is still mirrored to ctx.storage on every append and hydrated before flushing.
  • paramsShape() / writerParamsShape() now return Record<string, z.ZodType<string | undefined>> rather than ZodTypeAny. Under zod 4 a bare ZodTypeAny shape infers unknown handler args, which no longer matches the shared runGetter/runWriter signatures.
  • props is re-narrowed to non-optional via declare props: AuthProps — 0.21.0 types it props?: Props, but every /mcp request passes OAuthProvider bearer validation (which injects the props) before the DO runs a tool. declare emits no field, so the base class keeps ownership of the value.

Notes

  • One-time session reset on deploy. 0.21.0 gates sessions on an initializeRequest storage key that 0.0.98 never wrote, so every live MCP session receives Session not found (-32001) on its first request after this deploy. Spec-compliant clients re-initialize transparently; worst case is one retried call per session.
  • Verified before shipping: tsc --noEmit clean, 154/154 unit tests pass, wrangler dev boots (/docs 200, unauthenticated /mcp 401s correctly), wrangler deploy --dry-run bundles, and an in-memory MCP client↔server harness confirms every schema shape this server uses (string/optional/default, and the z.coerce.number().int().min().max().default() topN chain) still registers, serializes to clean draft-07 JSON Schema in tools/list, coerces topN: "15"15, and applies defaults — i.e. the SDK-1.30/zod-4 combination does not reintroduce the tool-discovery serialization failure documented in CLAUDE.md.
  • McpAgent is now marked deprecated / feature-frozen upstream in favour of createMcpHandler. That migration was assessed this session and deferred — it is simultaneously an MCP SDK v2 move and a drop to a stateless, Durable-Object-free handler, and the cost sits in the DO-resident audit-log buffer rather than the tools. Full cost breakdown and recommended sequencing are in CLAUDE.md → "Deferred — createMcpHandler migration".