carlos / platform Public

Offline move: stage should refuse a target holding an old live link; status after a staged abort open

These came from the first production moves with stage (v0.28.7, 2026-10-21).

  1. A target's old /opt/carlos/live/<host> link is found only at flip, after the instance is offline. A move attempt on 2 Oct left a root-owned live link on the target box, pointing at an old build. Today's move staged fine, and start and seal passed, but flip failed the landing's release item (exit 4), and the instance was offline for about 2 min before the abort brought it back. The check belongs in stage and start, while the instance still serves: the target box should report the host's live link, and the doors should refuse with a clear sentence before anything goes offline. Also wanted: a supported road to clear a stale link (today it took root by hand on the box), and a sweep for links whose host has no route on that box.
  2. Status is misleading after an abort from staging. It says "Moving … back to ie" and lists 22 checks as waiting, though nothing ever moved (dev rehearsal, 2026-10-21). This needs a copy fix.
  3. The seal does not say how many objects it copied. Operators count from the bucket's versions; the stage rounds report their counts.

More from the second batch of production moves (2026-10-21, v0.28.7):

  1. The seal refuses extra app directories only after the instance is offline. An instance that keeps /data/.instances/<host>/data (or documents/, blobs/) beside its files directory fails seal with exit 4 ("this move can carry only the files directory"), after start has already stopped it: 75 s offline, then abort. Four of one account's instances had such a directory, all empty. This is the same class as point 1: stage and start should refuse up front. Better still, the move should carry app directories, or at least empty ones. The workaround used, with Paul's approval: after start, check the directory is empty and remove it with rmdir. The app recreates it on the target if it needs it.
  2. Runbook Appendix A fixes (docs/superpowers/plans/2026-10-21-offline-move-runbook.md): - facts.box.sh must print the empty-tree digest when there is no files tree; - procs.box.sh must count the slice's processes recursively, because the instance runs in a child cgroup. As written it always reported 0.
  3. After open, the source box and DNS answer 503, not the 404 the runbook says, for 6 to 19 s.
  1. For the hour before it nests, a moved instance runs flat on the target and writes its app directories into the box's SHARED /data. Two instances that were moved earlier recreated documents/ and blobs/ as /data/documents and /data/blobs on the target, not under their own host. Two instances of the same app, both flat at the same time, would share one directory. The operator held the second move until the first had nested. The orphans are empty and left in place. The move should land the instance nested, or the flat layout should never resolve app directories to the shared /data.
  2. Custom-domain aliases answered 404 through the source box and DNS for about 4 minutes after open, until the target's DNS check ran. They then recovered on their own. The move does not carry the aliases' verified status.