# Mastra 1.83 Migration: Reconnecting Is Not Crash Recovery

Check agent execution, cancellation and MCP exposure before treating a successful upgrade as a safe deployment.

By Paras Madan | 2026-11-14

Mastra 1.83 changes what `durable` means on a plain agent: it now configures resumable streams, not checkpoint-backed execution. If your application relies on an agent surviving a server restart, upgrading packages and reconnecting the chat interface are not enough. You need to check the execution wrapper and recovery configuration separately.

The [release notes](https://github.com/mastra-ai/mastra/releases) list this as a breaking change. GitHub records the release on November 13, although its heading says November 12. The practical migration question is what survives when a browser, connection or server disappears.

## Decide which failure you need to survive

According to the [resumable-stream documentation](https://mastra.ai/docs/agents/resumable-streams), agents registered on a `Mastra` instance publish streams by default; standalone agents do not. A plain agent's `durable: true` enables streams, while `durable: false` disables them. Publishing and replaying events lets a reader reconnect. It does not restart a dead execution process.

With streams enabled, disconnecting a reader leaves the run working, including model requests and tool calls. Closing a tab is therefore not a cancellation mechanism. Decide whether your product means “continue in the background” or “stop when I leave,” and make that choice visible to the person using it.

**A reconnect test and a crash-recovery test prove different things.** A chat transcript filling back in after refreshing the browser says nothing about whether an unfinished tool call will survive a deployment.

## Migrate checkpoint-backed execution explicitly

For execution that needs checkpoints, the [durable-agent guide](https://mastra.ai/docs/harness/durable-agents) uses `createDurableAgent` from `@mastra/core/agent/durable`. Wrap the existing agent, register the wrapper, configure persistent workflow storage and enable `recovery: { durableAgents: 'auto' }` for automatic restart recovery.

The recovery default is off. Under the default persistence policy, that means ordinary in-flight `running` snapshots are not continually written before shutdown. A custom snapshot policy can change this behavior, so audit it rather than assuming the wrapper alone guarantees recovery.

Recovery resumes from the last saved snapshot. An unsaved tool result can cause the tool to run again; an unsaved model response can require another billed request. External actions need idempotency: the same logical operation should not create a second invoice, notification or database mutation when retried.

For example, give a simulated invoice operation a stable business-operation ID, and have the receiving test service return the existing result when that ID repeats. Do not generate a fresh ID inside every retry. This is a proposed migration test, not a claim that I ran your application or tested this release.

## Check the new MCP surface before deployment

There is a separate server change worth reviewing in the same upgrade. The [built-in MCP documentation](https://mastra.ai/docs/server/mcp) says `/api/mcp` is enabled in production when `server.auth` is configured. It requires the optional `@mastra/mcp` dependency; without that package, the route returns 501. Production without auth defaults to 404, while development serves the endpoint.

If you do not intend to expose it, set `server.mcp.enabled` to `false`. Do not solve an authentication error by forcing it on without auth: the docs warn that reachable clients could then invoke your agents, workflows and tools. Existing HTTP permissions still matter, but “we already have authentication” is not a decision about which clients should receive this interface.

For an intentional rollout, review the selected toolsets and include/exclude rules with a restricted test identity before connecting a broadly privileged assistant.

## A staging test that separates the risks

Use synthetic data and a harmless tool that records operation IDs. These are suggested acceptance checks, not reported test results:

1. Start a multi-step run, disconnect only the client, then reconnect. Confirm the interface follows the original run rather than launching another.
2. Repeat the test but stop the server process. Check the saved state and recovered execution separately from the visible transcript.
3. Interrupt immediately after the test service records a tool action. Confirm recovery does not create a second business operation.
4. Exercise your explicit stop control. Verify the downstream service's state, not just a stopped spinner.
5. Inspect MCP access using an unauthorized caller and your intended restricted identity. Confirm the available operations match the access you planned.

The valuable part of this upgrade is that stream delivery and execution recovery can be chosen separately. Keep them separate in your tests too. Otherwise a more reliable-looking chat interface can hide an execution path you have never actually verified.

I’m Paras. I work across AI, engineering and technical storytelling.

I help technical teams turn complicated product changes into clear guides developers can use.

[Book a 30-minute call](https://cal.com/paras-madan/30min).