bug: renamed agent's soft-delete recovery mounts a fresh empty workspace volume (rename keeps the old volume)

[dolho]

Found while fixing #1664 — deliberately left out of that PR to keep the P0 data-loss fix tight.

Summary

Rename keeps the agent's Docker volumes under the pre-rename base (agent-{old}-workspace); the live container carries the mount forward, so the running agent is fine. But three code paths still derive the volume name by f-stringing the agent's current name, which for a renamed agent points at a volume that does not exist:

• services/agent_service/lifecycle.py::recreate_missing_container (bug(recovery): soft-delete recovery dead-ends — recover tells you to start, but start 404s when the container is gone #1559 soft-delete recovery) — base_volumes = {f"agent-{agent_name}-workspace": ...}. Recovering a renamed, soft-deleted agent creates a fresh empty volume and starts the agent on it. The real data volume survives on disk (untouched, and bug: #1581 orphan-volume sweep can destroy a live renamed agent's home volume (rename keeps old volume name+label) #1664 keeps the sweep off it), but the agent comes back with an empty /home/developer — silently.
• services/agent_service/lifecycle.py::_read_template_yaml_from_volume (bug(recovery): soft-delete recovery dead-ends — recover tells you to start, but start 404s when the container is gone #1559) — reads template.yaml from agent-{agent_name}-workspace; for a renamed agent that volume is absent, so it falls back to defaults ({}) instead of the committed template metadata (agent-type / runtime).
• services/agent_service/deploy.py::_prepopulate_workspace_from_template uses the same convention (fine today — deploy names are fresh — but it is the same latent assumption).

Fix

#1664 added the primitive: agent_ownership.volume_base_name (NULL ⇒ agent_name) + db.get_volume_base_name(agent). The purge path and the orphan sweep already resolve through it. These paths should too:

base = db.get_volume_base_name(agent_name) or agent_name
base_volumes = {f"agent-{base}-workspace": {"bind": "/home/developer", "mode": "rw"}}

A repo-wide grep for f"agent-{...}-workspace" is the audit — every site that means "this agent's volume" must go through get_volume_base_name, never the current name.

Repro

1. Create agent old, write files to its workspace.
2. Rename old → new.
3. Soft-delete new, then recover it via POST /api/admin/soft-deleted/agents/new/recover.
4. POST /api/agents/new/start → container comes up on a brand-new empty agent-new-workspace; the data sits unreferenced in agent-old-workspace.

Related

• bug: #1581 orphan-volume sweep can destroy a live renamed agent's home volume (rename keeps old volume name+label) #1664 (the P0: the sweep destroying that same volume) — added volume_base_name + get_volume_base_name
• bug(recovery): soft-delete recovery dead-ends — recover tells you to start, but start 404s when the container is gone #1559 (soft-delete recovery gap / recreate_missing_container)
• Agent runtime data volumes: declared data paths with snapshot/restore and portable export #1169 (durable agent home volumes / data_paths) — the data class at stake

[dolho]

PR #1668 (stacked on #1666 — it needs that PR's db.get_volume_base_name primitive).

Reproduced exactly as filed, and the mechanism is worse than "creates a fresh volume": containers.run creates a missing named volume rather than failing, so recovery rebuilt the agent on an empty /home/developer and started it — the agent comes back looking healthy, just empty.

recovery mounts today : agent-r1665-new-workspace
   -> agent sees      : <volume does not exist -> docker CREATES it empty>
resolved via #1664 pin: agent-r1665-old-workspace
   -> agent sees      : the agents real data

All three sites this issue named are fixed and verified mock-free (real DB + real daemon): recovery now mounts the real data; the template read recovers the committed researcher/codex instead of silently falling back to defaults; and the dead agent_volume_name assignment in recreate_container_with_updated_config is gone — it named the wrong volume convincingly enough to read as the mount in use, which is how this class spreads. deploy.py is correct by construction (fresh name, no row, no rename in its past) and is annotated as audited rather than changed.

Two things worth flagging beyond the issue:

• The audit found a fourth site this issue did not name: get_public_volume_name/get_shared_volume_name also name off the live agent name, and recreate_container_with_updated_config drops the old public/shared mounts and re-adds them by current name — so rename + any recreate silently empties a renamed agent's publish dir and shared-out folder. Filed as bug: rename + recreate silently empties an agent's public/shared volumes (they name off the live agent name) #1669 rather than bundled, because it is not a mechanical swap: agents already renamed in the field have been writing to agent-{new}-public, so resolving to the pinned base would orphan that data instead. It needs an adopt/migrate decision.
• The mock trap from fix(volumes): rename-safe volume identity — sweep, purge, create and recovery (#1664, #1665, #1667) #1666 recurred: the existing bug(recovery): soft-delete recovery dead-ends — recover tells you to start, but start 404s when the container is gone #1559 recreate test mocks the whole database module, and an unstubbed MagicMock attribute is truthy — it would be f-stringed straight into the volume name. Stubbed explicitly.

[dolho]

Retargeted: this is now fixed in #1666 (was #1668, folded in).

The two PRs shared a root cause and a primitive, and this one could not merge before #1666 regardless — meanwhile a stacked PR gets no CI test net on this repo (backend-unit-test.yml only triggers for PRs targeting dev/main), so the split cost coverage and bought nothing. Same commit, no rewrite; #1666 now carries both and runs the full base-vs-head suite on every push.