🏗️ Architecture: Session 178: Are persistent VM snapshots working end-to-end?...

Date: 2026-03-05
Time: 18:51:45 UTC
Session: gspace1-178.18
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Session 178: Are persistent VM snapshots working end-to-end? What bugs remain?

Task: Not specified

🎯 Decision Made

Chosen:

Snapshot creation: WORKS (Firecracker PATCH /vm pause + PUT /snapshot/create). Restore: WORKS after 3 fixes: (1) socket path mismatch fc.sock vs firecracker.sock, (2) PATCH /vm instead of PUT for pause, (3) rootfs must be at original path because Firecracker snapshot embeds absolute drive paths. Remaining gap: SandboxManager doesn't track restored VMs in its sandboxes map — restored VM exists at Firecracker level but manager returns 'not found'. Production flow works because ComputerUseLoopService uses the provider handle directly.

Options Considered:

• No alternatives documented

💭 Reasoning

Three cascading bugs in snapshot infrastructure, similar to the 3-bug cascade in Session 177 VM boot. Bug 1: createSnapshot used hardcoded 'firecracker.sock' but startVM creates 'fc.sock' — fixed by using proc.socketPath. Bug 2: Firecracker v1.7 requires PATCH /vm for state changes, not PUT — fixed by adding method parameter to putSocket. Bug 3: Firecracker snapshot state file embeds absolute rootfs path — restore must recreate the rootfs at the SAME path, not a new session directory. Fixed by reading original sessionId from metadata and copying rootfs to that path. The destroy-before-restore requirement is satisfied by the production ComputerUseLoopService flow (lines 354-364).

📁 Files Involved

• No files specified

🔗 Related

• Decision ID: dev_1772736705619_1b0whbt
• Session: 178
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation