Feature/self-updating-mastra

[raphaeltm]

Samples Checklist

✅ All good!

[lionello]

Comments:

• add a "reboot" (ie. die) button so we come back with old state.
• file changes should ideally be atomic, because changes that touch many files will result in tons of auto-submitted client errors.

[lionello]

use the new model runner syntax models:

[lionello]

set replicas: 1 to avoid multiple split-brain

[defang-sam]

Thanks @lionello — addressed all four points in adc3082:

1. Reboot / "die" button — added a Reboot environment control to the admin recovery console. It kills PID 1, so the container's restart: unless-stopped policy brings it back from the last published image (returning to the last-published state and dropping edits made since). It's refused mid-run/mid-publish so it can't tear down an in-flight write, and the UI treats the dropped connection as success.

2. Atomic file changes — a run is already transactional at the git level (commit on success, revert on failure), but its one-file-at-a-time edits hot-reload through transient broken states that flooded the backlog with auto-captured errors. recordError now skips auto-captured client/server errors while a run is in flight, so a run is atomic from the observer's side too. Errors from the final committed state are still captured, and it fails open if agent_runs isn't available.

3. models: runner syntax — migrated the chat managed LLM from the provider: { type: model } block to the top-level Docker Compose models: key, referenced by the dev service via endpoint_var/model_var (in both compose.yaml and compose.dev.yaml).

4. replicas: 1 on the db — set on the Postgres service to avoid a split-brain second database.

Note: I validated both compose files parse and the admin console script parses, but did not run a full tsc/deploy from this environment (Mastra deps not installed here) — the sample build/CI covers that.

[defang-sam]

Follow-up on the review feedback (commit b4f302c):

1. replicas: 1 — you're right, it belongs on dev (already set) to keep a single working copy; removed the one I'd wrongly added to db and left DB scaling to the platform.

2. Atomicity via worktrees — agreed the real issue is that the dev server serves the same files being edited, not a separate checkout. The coding agent now edits an isolated git worktree and typechecks there; a successful run is fast-forwarded into the live served tree in a single step (agent/src/paths.ts, git.ts: syncAgentWorktree/commitRun/applyToLive), so the dev server sees one atomic, already-typechecked update. Failed runs are discarded in the worktree and never touch the live app. This supersedes the error-suppression hack from the last commit, which I reverted. entrypoint.dev.sh creates the worktree, shares the image's node_modules, and prunes the stale worktree registration that rides in .git across a self-redeploy.

3. AWS deployment — the deployed chat model was GCP-only (gemini-2.5-flash, which resolves to a non-existent bedrock/gemini-2.5-flash on AWS). Switched it to ai/chat-default so Defang resolves it per provider (Gemini on Vertex, Claude on Bedrock) and the same Compose file deploys to both. Committed a .defang/aws stack (us-east-1) and documented GCP + AWS deploys in the README.

Verification status: the agent TypeScript typechecks (tsc --noEmit) and both compose files + the admin console script parse. I could not run an actual deploy from this environment (no CLI/creds), and the worktree + self-redeploy path really wants a live deploy to confirm — particularly (a) the worktree recreation across a publish self-redeploy and (b) ai/chat-default on Bedrock. Happy to dispatch a deploy-and-verify run to GCP beta and AWS if you want.