Mastra background tasks and Sume: reuse the idempotency key

Mastra 1.72.0 fences background tasks with leases. If a new owner restarts a Sume tool call, the same idempotency key returns the original job.

4 min readSume
All posts

If a recovered Mastra background task restarts a Sume tool call, the call must reuse the same idempotency_key. Sume's REST docs say a same-key retry returns the original job instead of billing a second one, and the new lease owner can keep waiting on the same job_id. The MCP docs I read do not spell out the replay result per tool, so confirm with jobs_status.

Mastra facts are from the @mastra/core 1.72.0 release notes (2026-09-30); Sume behavior from Jobs and results and MCP tools and gates, read 2026-09-30.

What does Mastra 1.72.0 change?

Background task execution is now lease-fenced: a running task records which worker owns it and when the lease lapses, set with leaseDurationMs. Recovery only reclaims a task whose lease has expired, and a worker that lost ownership can no longer save a result. Durable agents also honor the awaited disposition, keeping the model turn open until the tool result is persisted; replayed steps adopt the matching persisted task and resume or restart it by status.

Why can a Sume call run twice?

"Restart it according to its status" means the tool body can execute again under a new owner. A paid Sume tool call executed twice with different keys is two jobs. Sume's gate table says the idempotency_key is required on write and paid tools and is a stable key for transport and dedup, not human approval.

Recovery cases for a Sume tool call, from the Mastra release notes and Sume docs read 2026-09-30.
CaseWhat to do
New owner restarts the toolSend the same idempotency_key; the REST docs say the original job comes back
Old owner finishes lateMastra rejects its save; the job still exists on Sume
Wait runs longRepeat jobs_wait; do not ask for a longer single wait

How do I derive a stable key?

Build the key from the task, not the attempt: for example the persisted background task id plus the tool name. The docs say to reuse the same key only for the same operation and payload, so a changed prompt needs a new key.

How long should the tool wait?

A wait is bounded per call. The docs say to wait for a ten-minute render by repeating the wait. Poll with jobs_status or jobs_wait, then read jobs_result. Set leaseDurationMs with the wait slices in mind, since recovery reclaims a task once its lease has expired. More on the MCP side in Mastra MCP client with Sume.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume