On next since main, reviewed, tagged v1.0.0-rc4: the health check answers 503 with statuserror when every lookup in the last round of DNS checks got no usable reply from a root server, as on a network that intercepts DNS queries (#302). Before that it answered ok while dnswatcher checked nothing.
To know before merging or deploying:
If fsn1app1 cannot reach the root servers, or answers DNS queries itself, the container turns unhealthy when the first round of checks finishes; until then the health check answers ok. If that round ends within the 60 seconds upaas waits, upaas marks the deploy failed.
A network outage that fails a whole round keeps the health check at error until the next round, up to DNSWATCHER_DNS_INTERVAL (1 hour by default).
Merge with a merge commit, as last time: next contains main, and a squash makes them diverge.
#303 (main into prod) is the deploy. Merge this first and that PR carries this fix as well.
No known bugs are open.
Model: opus-5-5
On `next` since `main`, reviewed, tagged `v1.0.0-rc4`: the health check answers 503 with `status` `error` when every lookup in the last round of DNS checks got no usable reply from a root server, as on a network that intercepts DNS queries (https://git.eeqj.de/sneak/dnswatcher/issues/302). Before that it answered `ok` while dnswatcher checked nothing.
To know before merging or deploying:
- If fsn1app1 cannot reach the root servers, or answers DNS queries itself, the container turns unhealthy when the first round of checks finishes; until then the health check answers `ok`. If that round ends within the 60 seconds upaas waits, upaas marks the deploy failed.
- A network outage that fails a whole round keeps the health check at `error` until the next round, up to `DNSWATCHER_DNS_INTERVAL` (1 hour by default).
- Merge with a merge commit, as last time: `next` contains `main`, and a squash makes them diverge.
- https://git.eeqj.de/sneak/dnswatcher/pulls/303 (`main` into `prod`) is the deploy. Merge this first and that PR carries this fix as well.
No known bugs are open.
Model: opus-5-5
The health check answered ok while every DNS lookup failed, as on a
network that intercepts DNS queries. A lookup whose root servers give no
usable reply now fails with ErrNoRootServerAnswered. At the end of each
round of DNS checks that shutdown did not cut short, the watcher records
whether every lookup failed with it or with ErrIntercepted; the health
check then gives status error, and /.well-known/healthcheck and /health
answer 503. Until the first round finishes it stays ok.
The health check now depends on the watcher, so fx starts the watcher
before the HTTP server and stops the server first. NewWithRootServers
lets tests start a resolver's walks at real servers that are not root
servers.
Model: opus-5-5
sneak
was assigned by clawbot2026-10-18 17:29:01 +02:00
clawbot
added this to the 1.0 milestone 2026-10-18 17:29:02 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
On
nextsincemain, reviewed, taggedv1.0.0-rc4: the health check answers 503 withstatuserrorwhen every lookup in the last round of DNS checks got no usable reply from a root server, as on a network that intercepts DNS queries (#302). Before that it answeredokwhile dnswatcher checked nothing.To know before merging or deploying:
ok. If that round ends within the 60 seconds upaas waits, upaas marks the deploy failed.erroruntil the next round, up toDNSWATCHER_DNS_INTERVAL(1 hour by default).nextcontainsmain, and a squash makes them diverge.mainintoprod) is the deploy. Merge this first and that PR carries this fix as well.No known bugs are open.
Model: opus-5-5