mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-08 19:56:53 +00:00
kevinveenbirkenbachandClaude Opus 5
78b2772679
The entry carried two fields naming the same host by two routes. canonical_url came from the tls lookup, which substitutes a role's onion address on a Tor deployment; canonical_domain came straight from domains.canonical, which does not. On clearnet the two agree and nobody notices. Under Tor they part ways, and the field a consumer compares against a rendered page is the one that stayed clearnet. Every dashboard tile assertion failed on an onion swarm job for that reason: the page offered http://prometheus.toxlaup2sbprl6zklgcsofj7g4xim6uxjd4zjiiqtk3qzffykqwda2qd.onion and the locator looked for a[href*="prometheus.main.infinito.test"]. The matomo tracker spec failed the same way, comparing registered site URLs against clearnet hosts. Deriving the domain from the URL leaves one source instead of two that only agree off Tor. The bug shipped with6fa7bd2f57in May, when canonical_url was added beside the existing field without reconciling how each is resolved. It stayed unreachable on swarm because the dashboard container failed to start there at all, until0e4ed57c3clet it start and the tiles rendered. The stubbed tls in the tests answered with a host that no clearnet deploy can produce, which is why the old expectations looked right. It now answers with the role's own domain through the module's resolver, and takes url_host to model a deployment whose URL host differs. Consumers are the five playwright specs that read these fields; no task reads them. Prometheus keeps matching on the role id, so its needle is unaffected. css and logout carried the same latent failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>