feat(core): thread agent and thread identity through the processor surface#18552
feat(core): thread agent and thread identity through the processor surface#18552CalebBarnes wants to merge 1 commit into
Conversation
Processors had no sanctioned way to learn which agent, thread, or resource a run belonged to, forcing consumers like ChatChannelOutputProcessor to depend on request-scoped side channels. Add agentId, agentName, threadId, and resourceId as flat optional fields on ProcessorContext so every processor method receives them. Both the in-process ProcessorRunner path and the workflow-as-processor path carry identical identity fields: identity is added to every hand-built args object, lives on the workflow step schemas to survive serialization, and is spread into baseContext in both workflow executors. A cross-path symmetry test proves a processor receives the same identity regardless of path. Co-Authored-By: Mastra Code (anthropic/claude-opus-4-8) <noreply@mastra.ai>
🦋 Changeset detectedLatest commit: 95c066b The changes in this PR will be included in the next version bump. This PR includes changesets to release 22 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
|
Superseded by #18630. The self-sufficient channels output processor (the only consumer of this identity work) instead sources the run's threadId from the framework-populated |
Summary
Processors today have no first-class way to learn which agent, thread, or resource a run belongs to. Consumers that need this (for example the channels output processor) are forced to depend on request-scoped side channels that are not always populated. This PR adds
agentId,agentName,threadId, andresourceIdas flat optional fields onProcessorContext, so every processor method receives them directly.The fields are optional and
undefinedfor non-agent or threadless pipelines, so existing processors keep working unchanged.What changed
ProcessorContext(propagates to all method arg types).agentIdto theProcessorRunnerconstructor alongsideagentName;threadId/resourceIdare passed per-call into the public entry methods.baseContextin both the default and evented workflow executors.agentId(and properagentName/threadId/resourceIdwhere available) into all non-testProcessorRunnerconstruction sites.All four fields are plain strings, so they cross the workflow step serialization boundary safely. No live handles or closures were added to any step schema.
Test plan
runner.test.ts: a processor receives identicalagentId/agentName/threadId/resourceIdwhether it runs in-process or as a workflow.pnpm build:core— passing.pnpm --filter ./packages/core check(typecheck) — passing.src/processors/, 38 files) — passing.This is PR #1 of a stack. It is independently useful and unblocks a follow-up that makes the channels output processor self-sufficient.