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.

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.
| Case | What to do |
|---|---|
| New owner restarts the tool | Send the same idempotency_key; the REST docs say the original job comes back |
| Old owner finishes late | Mastra rejects its save; the job still exists on Sume |
| Wait runs long | Repeat 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
- MCP stream dropped: re-issue with the same idempotency_key
MCP 2026-07-28 says re-issue a broken request with a new request ID. On a paid Sume tool, keep the same idempotency_key so the retry is not a second charge.
- MCP tool name with a dot or underscore: tools.list vs tools_list
Sume MCP tool ids use underscores; a dotted alias such as tools.list is canonicalized on call. Retired aliases map to generate_image and generate_video.
- MCP OAuth token expires: Sume's one-hour token, no refresh
Sume's hosted MCP OAuth access tokens last one hour and the server advertises only the authorization_code grant, so re-login or use an API key for long runs.
- MCP traceparent in _meta: tracing a Sume tool call end to end
MCP 2026-07-28 documents traceparent in _meta. Sume's docs don't describe reading it, so correlate with the job id and x-sume-request-id instead.
Written by Sume