[FEATURE] Support AbortSignal cancellation for Docker template preparation
Problem Statement
PR #24199 adds reusable Docker templates and exact-build readiness. A follow-up lifecycle capability would make that preparation usable in cancellable jobs: the API introduced by that PR does not expose an AbortSignal for DockerTemplate.build() or propagate caller cancellation through repository-template resolution and lazy builds during sandbox startup.
Template preparation can involve repository access, cloning, package installation, and compilation. If a user cancels a job, a CI deadline expires, or an application shuts down, callers need to stop preparation and release its resources. Racing the returned promise against cancellation only stops waiting; it does not stop the underlying work.
Proposed Solution
Add an optional AbortSignal to Docker template preparation and propagate it through the relevant public entry points. The exact option name can follow Mastra conventions.
Expected behavior:
- DockerTemplate.build() accepts caller cancellation. An already-aborted signal starts no build; an abort during preparation stops the underlying build work and closes its streams and BuildKit session.
- Repository-template resolution propagates cancellation to the Git lookup and exposes the signal to asynchronous repository-access/build-environment resolvers where necessary.
- Builds triggered by createSandbox() or DockerSandbox startup can use the same cancellation path, so callers do not lose cancellation when using lazy preparation.
- Cancellation has a distinguishable outcome consistent with existing sandbox errors. It must not report the cancelled operation as ready or publish an incomplete result as a usable template. Preserve previously successful cached images and allow a later attempt to succeed.
- Document how cancellation interacts with queued or shared in-flight builds. Cancelling one waiter should not unexpectedly terminate work still required by another caller; an explicit build-owner model is also reasonable. If no caller still needs a build, cancellation should stop it.
Please include coverage for pre-abort, abort during repository lookup/build, resource cleanup, retry after cancellation, and shared/queued callers. A separate timeout option is not essential if callers can supply a deadline through AbortSignal.
Component
Workspaces
Alternatives Considered
- Promise.race() or a caller-side timeout: returns control to the application but leaves preparation consuming resources.
- Always wait for preparation to finish after cancellation: can delay job cancellation and graceful shutdown for long installs or builds.
- Manage Docker builds directly outside Mastra: allows custom cancellation handling but duplicates the build/session lifecycle that DockerTemplate now owns.
Example Use Case
A coding-agent job prepares a template before starting several disposable sandboxes. The user cancels the job while dependencies are installing.
The application aborts the job controller. Preparation should terminate, release build-session resources, and settle with a cancellation outcome. No agent sandbox should subsequently be started for that cancelled job. A later job should be able to retry preparation normally.
The same capability supports CI deadlines and application shutdown. If another active job shares the build, the cancellation policy should let that job continue without keeping the cancelled caller waiting.
Additional Context
Follow-up to https://github.com/mastra-ai/mastra/pull/24199, which implements https://github.com/mastra-ai/mastra/issues/24136.
The original reusable-template feature is delivered; this request concerns cancellation across its preparation lifecycle. Reference implementation reviewed: f35f2baf2b09bbb055d2013612ab224733a2b5a0.
Relevant source:
- https://github.com/mastra-ai/mastra/blob/f35f2baf2b09bbb055d2013612ab224733a2b5a0/workspaces/docker/src/template/template.ts
- https://github.com/mastra-ai/mastra/blob/f35f2baf2b09bbb055d2013612ab224733a2b5a0/workspaces/docker/src/template/repo-template.ts
The scope is cancellation of preparation, not local-repository import, process checkpointing, or automatic deletion of successful template caches.
Verification
- I have searched the existing issues to make sure this is not a duplicate
- I have provided sufficient context for the team to understand the request
Source: mastra-ai/mastra