kevinveenbirkenbachandClaude Opus 5 f74b4a8715 fix(web-app-docs): stop the replay losing to its own snapshot and resolver ...

Three defects in the CLI replay of run 39186571513, independent of each
other.

docs#0 (117856696140) failed at tasks/main.yml with

  tar: cli/administration/deploy: file changed as we read it   rc=1

The task archives the live checkout while the controller keeps running
Python out of it. A __pycache__ appearing under a package directory
moves THAT DIRECTORY's mtime, and a recursing tar re-stats directories
after scanning them, so --exclude keeps the entry out of the archive but
cannot stop the parent from changing underneath. Measured on a fixture:
plain tar exits 1, --warning=no-file-changed silences the message and
still exits 1, and the list-first form exits 0 with the three patterns
absent and parents still ahead of their children under LC_ALL=C.

tor#1 (118545536787) failed one layer deeper, at
svc-net-tor/tasks/router.yml:67, 'Unable to start service dnsmasq'. The
replay's CoreDNS shares the target's network namespace
(network_mode: service:machine) and both server blocks declared :53
without bind, so it held the wildcard including 127.0.0.1:53 and
dnsmasq, which binds listen-address=127.0.0.1 with bind-interfaces,
could never start. Inference, not observation: machine.sh destroys the
replay target on exit, so no journal for that dnsmasq exists in any
artifact. The same config starts fine on the CI VM in the same job.

That missing journal is the third defect. report_failed_units asked
systemctl --failed, which does not list a unit parked in
activating/auto-restart by a Restart= drop-in -- exactly where
router.yml:59 had just put dnsmasq. The only unit it printed was an
unrelated systemd-modules-load.service. Naming the states restores the
diagnostic; the function still runs only on the failure path and
returns 0 regardless, so nothing it reports can fail a test.

Expect one more tor#1 failure after this: once dnsmasq starts,
svc-net-tor rewrites the target's resolv.conf to 127.0.0.1 and drops
the harness wildcard. Only firewall assertions follow and they need no
DNS, so it is not pre-fixed here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-10-20 19:11:59 +02:00

..

main.yml

fix(web-app-docs): stop the replay losing to its own snapshot and resolver

2026-10-20 19:11:59 +02:00