Mastra idleTimeoutMs observer detach: the Sume job keeps running

A Mastra release changed what happens when idleTimeoutMs fires without an isAlive probe: the observer now detaches, and the run's registry entry and cached events are kept. A Sume job started by that run is not touched either way. It keeps running and billing until it finishes or you call jobs_cancel.

Vendor facts are from the Mastra releases page; Sume facts from Jobs and results and MCP tools and gates, read 2026-10-01.

What does the Mastra note say?

Before, a quiet but still-running run, such as one waiting on a slow tool, was cleaned up. Now it is kept. The note says that if you rely on the idle timeout to clean up runs whose process crashed, you should pass isAlive so cleanup happens only when the run reports itself not alive.

What does that leave on the Sume side?

Three separate states can exist after a detach.

How do I reattach?

Keep the job ids from the create result in the run state. After the observer detaches, call jobs_wait with the same ids. The docs say never to resubmit the paid create, so a second run that sees an existing id should wait on it. For the lease pattern in Mastra, see Mastra background tasks and Sume job leases.

When should I cancel instead?

If the run was abandoned on purpose, cancel its jobs; otherwise they continue to bill. jobs_cancel needs write access (mcp:write or an API key). Read tools such as jobs_status and jobs_result do not.