mirror of
https://github.com/CopilotKit/CopilotKit.git
synced 2026-09-14 16:26:20 +08:00
Benjamin Taylor
d735f67bc4
A starter scaffolded with `--framework mastra` accepted a chat message and never answered. The run aborted server-side with `Thread <id> not found`. `@ag-ui/mastra` writes the UI's shared state into Mastra working memory before it streams a turn (`syncInputStateToWorkingMemory`). That write is unguarded and never creates the thread, because it assumes the resource-scoped store, which upserts. The starter was the one Mastra agent in this repo that set `scope: "thread"`, which routes the same write to thread metadata and requires the thread row to exist. On the first turn of a conversation it does not, so `@mastra/memory` throws and the run dies before the model is called. Managed Intelligence made that certain rather than likely: the Intelligence run handler swaps the client thread id for a platform-canonical one, which the Mastra store has never seen. That is also why two different thread ids appear in the same failure. Verified against @mastra/core 1.41.0, @mastra/memory 1.0.1-alpha.1 and @ag-ui/mastra 1.1.2: thread scope throws on a fresh thread, resource scope writes, reads back, reaches the agent's system message, and stays per conversation because the bridge derives the resource id from the thread id. Every other Mastra agent here omits `scope`, so this aligns the starter with them. The gate is a new contract test in the parity workflow's suite. Left upstream: the adapter's local branch is still unguarded, so a developer who chooses thread scope hits the same abort. Its remote branch already creates the thread and retries. Worth a follow-up in ag-ui. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>