Daily Edition Sources +3

In Mastra’s Approval Queue, the Second Yes Needs Its Own Address

An open Mastra core pull request treats a human approval as a per-tool-call decision, not a vague signal attached to an entire agent run.

Two approval cards route through separate tool-call identifiers and a queued resume path, with an open pull request caveat stamp.
Diagram Punkone approval must point to one suspended workflow.
repo mastra-ai/mastra evidence
3 source signals 1 repo commit 66bbfb5
Evidence: commit 66bbfb5 / August 10, 2026 / Daily Edition
Open Edition Evidence below

Human approval is meant to slow an agent down at the consequential moment. But when one agent run asks for permission to continue two workflows at once, a single undifferentiated “yes” can become the new source of trouble. At mastra-ai/mastra, an open core pull request describes exactly that failure: sibling workflow-tool suspensions were stored under one parent run, so one could overwrite another; rapid approvals could also try to resume the same saved parent snapshot together.

The proposed repair gives each paused tool call its own address. It records the inner workflow run ID alongside the toolCallId, then queues resumptions for the same parent until the preceding stream pauses or finishes. In the public commit, the workflow step starts carrying suspendedToolRunId; the accompanying test creates two suspending workflows and approves them forward, reverse, and concurrently.

Approval is a routing problem before it is a button

The interesting part is not that Mastra adds a queue. It is what the queue protects: a human’s approval has to reach the particular suspended operation that asked for it. Otherwise an interface can show two legitimate permission prompts while the runtime still has only one place to put the answer.

The regression test makes the pressure visible. It waits for two suspended tool calls, sends approvals in each of the three possible ordering shapes, and expects two successful tool results with no stream errors. That is a practical definition of a trustworthy approval surface: the order in which a person clicks should not decide which workflow gets revived.

A proposal, not a release

The pull request remains open and awaits a required approving review. Its author reports focused tests and a successful core build; those are useful engineering receipts, not proof that a released Mastra version has the fix or that every production integration is safe. The next signal is concrete: a merge and release that retain the per-call identity, followed by public evidence on the related double-execution edge cases. Until then, teams building approval-gated workflow tools have a sharper audit question: can every prompt be traced to one suspended operation and one durable resume record?

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateAugust 10, 2026
LaneDaily Edition
Confidence78%
Sources3
Reposmastra-ai/mastra

Primary Evidence

Evidence Limits

  • The pull request is open. Its source and tests do not establish that the change is merged, released, deployed, or compatible with every Mastra integration.
  • The focused regression test establishes the named ordering cases under its mock setup; it does not establish security, authorization policy, or absence of other workflow-resume races.
  • The article reports the PR author’s validation statement as a statement attached to the proposal, not as an independent release certification.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.