Test write-authority transfer after durable-run takeover

Mastra’s @mastra/core 1.76.0 release introduces durable-run ownership and storage-level run fencing. According to the release, executions claim runs, recovery skips live claims unless forced, and supported storage adapters reject writes from executions that have lost ownership. It also warns when workflow or memory storage lacks fencing support (Mastra releases).

Those are documented release claims, not production validation. They nevertheless sharpen the engineering question behind recovery by takeover: after another execution takes over a run, can the former execution still change its messages, threads, or workflow state?

A successful restart does not answer that question. The stronger test for a takeover is whether write authority transfers cleanly.

The stale process is the hard case

Lease-based ownership has a familiar failure mode. Kleppmann describes how a client can pause long enough for its lease to expire, then resume and issue a stale write. His proposed protection is a fencing token attached to each write; the storage service remembers newer tokens and rejects older ones, so enforcement occurs at the protected resource (How to do distributed locking).

Applied to a durable agent run, the dangerous execution may not be dead. It may be paused by scheduling, a long operation, or another delay and then continue with an obsolete view of ownership. A recovery path involving takeover can therefore appear healthy while two executions remain capable of mutation.

That leads to an SGL design judgment: when recovery gives another execution control of a run, review it as a transfer of write authority, with restart behavior treated as only one part of the path. This framing is derived from the stale-writer problem; it is not a claim that every recovery involves a new owner or that Mastra deployments have exhibited this failure.

An ownership-transfer test card

Use one run and two execution identities: the original owner, A, and the recovery execution, B. Preserve the claim identifier, lease or expiry data, fencing value, attempted mutation, storage adapter, and result for every step.

Moment	Action	Evidence to retain
Initial claim	A acquires the run and writes once	Owner identity, fencing value, accepted write
Lease lapse	Prevent A from renewing without terminating it	Last renewal, expiry boundary, A still present
Takeover	B attempts recovery and acquires the run	New owner identity, newer fencing value, acquisition result
Current-owner write	B mutates run state	Accepted write tied to B’s fencing value
Stale-writer return	Resume A and attempt writes to every protected state surface	Rejection at storage, unchanged state, rejected fencing value
Adapter check	Repeat with each configured workflow and memory store	Fencing capability or explicit unsupported-storage warning

This card is a proposed verification artifact, not behavior established by the release announcement. Its purpose is to make the authority change observable across the whole write path.

The stale-write step is the center of the test. Do not stop after observing that B resumed the workflow. Resume A deliberately and attempt mutations against each relevant state surface. A useful result identifies the rejection point and shows that durable state did not change. A timeout, process termination, or application-level suppression is different evidence because it does not demonstrate storage-boundary enforcement.

Exercise the paths that weaken the claim

Mastra documents that recovery skips live claims unless forced (Mastra releases). That makes forced recovery a distinct case to test: record why takeover was allowed, which execution received the new authority, and whether A’s later writes are rejected.

Storage coverage also belongs in the result. The same release says fencing applies to supported adapters and warns when workflow or memory storage does not support it (Mastra releases). An unsupported warning is therefore material deployment evidence, not incidental log noise. It indicates that the documented rejection behavior cannot be assumed for that adapter from this release note alone.

Run the card against every configured state store rather than one convenient adapter. If messages, threads, memory, and workflow state travel through different persistence paths, record each path separately. This is a derived testing prescription: the supplied sources explain storage-level rejection and unsupported-adapter warnings, but they do not establish the topology of any particular deployment.

Also vary timing around the ownership boundary. Attempt A’s stale write immediately before takeover, during the acquisition race, and after B’s first accepted write. The objective is not to manufacture a performance benchmark. It is to locate the transition after which the older authority consistently loses.

Decide from the enforcement record

A restart log can show that work continued. When another execution takes over, an ownership-transfer record can show which execution was allowed to write, which one was rejected, where rejection occurred, and whether any configured adapter remained unfenced.

That distinction changes the release question for takeover recovery. “Did the run resume?” is too narrow on its own. A more useful bounded question is: “After takeover, did every protected storage path accept the current owner and reject the stale one?”

The answer belongs with the exact runtime and adapter configuration tested. Release notes document intended behavior; only a deployment-specific failure-injection run can establish what that configuration actually did. Teams building durable agent systems can carry this authority-transfer record into their broader infrastructure review on Build.