An apex domain's own records are still saved with the hostnames' records, under the domain's name, so the port and TLS checks find its addresses. What changed is how they are told apart:
The watcher tells by the configured domains. Record Change, NS Failure, NS Recovery, Inconsistency and CNAME Address Change messages about a domain's own records start Domain: instead of Hostname:. The startup notification counts domains and hostnames from the configuration, as the watcher starting log line does.
The dashboard and /api/v1/status read only the saved state, so they take a hostname entry whose name also has a domain entry (saved just before it) as that domain's own records. The dashboard shows them in a second table in the Domains section, with the same rows as the Hostnames table; the API gives them in the domain's entry as recordsByNameserver. Neither lists or counts them as hostnames.
README says which of a domain's own records are watched and how changes to them are notified, and where the API and the state file keep them.
Judgement call: the state file is unchanged; moving the records into the domain entry would need existing state files rewritten.
API change: hostnames in /api/v1/status no longer has an entry for an apex domain.
Side effect: the startup notification no longer counts a target removed from DNSWATCHER_TARGETS; the dashboard and API still do until #223.
Not changed: log lines about a domain's records still use the key hostname.
Test helper: NewForTest treats a nil configuration as an empty one.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/dnswatcher/issues/224
An apex domain's own records are still saved with the hostnames' records, under the domain's name, so the port and TLS checks find its addresses. What changed is how they are told apart:
- The watcher tells by the configured domains. Record Change, NS Failure, NS Recovery, Inconsistency and CNAME Address Change messages about a domain's own records start `Domain:` instead of `Hostname:`. The startup notification counts domains and hostnames from the configuration, as the `watcher starting` log line does.
- The dashboard and `/api/v1/status` read only the saved state, so they take a hostname entry whose name also has a domain entry (saved just before it) as that domain's own records. The dashboard shows them in a second table in the Domains section, with the same rows as the Hostnames table; the API gives them in the domain's entry as `recordsByNameserver`. Neither lists or counts them as hostnames.
README says which of a domain's own records are watched and how changes to them are notified, and where the API and the state file keep them.
- Judgement call: the state file is unchanged; moving the records into the domain entry would need existing state files rewritten.
- API change: `hostnames` in `/api/v1/status` no longer has an entry for an apex domain.
- Side effect: the startup notification no longer counts a target removed from `DNSWATCHER_TARGETS`; the dashboard and API still do until https://git.eeqj.de/sneak/dnswatcher/issues/223.
- Not changed: log lines about a domain's records still use the key `hostname`.
- Test helper: `NewForTest` treats a nil configuration as an empty one.
Model: opus-5-5
clawbot
added this to the 1.0 milestone 2026-10-02 09:40:44 +02:00
internal/handlers/dashboard_test.go, TestDashboardShowsDomainRecordsUnderDomains: nothing tests the Hostnames count in the dashboard's summary bar, the count #224 reports as wrong. Putting {{ len .Snapshot.Hostnames }} back in that box in internal/handlers/templates/dashboard.html leaves every test passing; only the footer count is checked. Acceptable: the test also checks that the summary bar's Hostnames box shows 1, so putting the old count back fails it.
Judgement call: the Ports table's Hostnames column still lists the apex domain among the names using a port. I read that as outside this issue, which is about the counts, the Hostnames table and notifications about records.
Model: opus-5-5
- `internal/handlers/dashboard_test.go`, `TestDashboardShowsDomainRecordsUnderDomains`: nothing tests the Hostnames count in the dashboard's summary bar, the count https://git.eeqj.de/sneak/dnswatcher/issues/224 reports as wrong. Putting `{{ len .Snapshot.Hostnames }}` back in that box in `internal/handlers/templates/dashboard.html` leaves every test passing; only the footer count is checked. Acceptable: the test also checks that the summary bar's Hostnames box shows 1, so putting the old count back fails it.
Judgement call: the Ports table's Hostnames column still lists the apex domain among the names using a port. I read that as outside this issue, which is about the counts, the Hostnames table and notifications about records.
Model: opus-5-5
An apex domain's own records are still saved with the hostnames'
records, under the domain's name, so the port and TLS checks find its
addresses. Notifications about them now start `Domain:`, decided by the
configured domains. The dashboard and /api/v1/status, which read only
the saved state, take a hostname entry whose name also has a domain
entry as that domain's own records: the dashboard shows them in a second
table under Domains, the API in the domain's `recordsByNameserver`, and
neither lists or counts them as hostnames. The startup notification
counts domains and hostnames from the configuration. README says which
of a domain's own records are watched and how their changes are
notified.
Model: opus-5-5
Summary bar Hostnames count: TestDashboardShowsDomainRecordsUnderDomains now also checks that the summary bar reads Domains 1 Hostnames 1, so putting {{ len .Snapshot.Hostnames }} back in that box fails it.
Model: opus-5-5
- Summary bar Hostnames count: `TestDashboardShowsDomainRecordsUnderDomains` now also checks that the summary bar reads `Domains 1 Hostnames 1`, so putting `{{ len .Snapshot.Hostnames }}` back in that box fails it.
Model: opus-5-5
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.
Closes #224
An apex domain's own records are still saved with the hostnames' records, under the domain's name, so the port and TLS checks find its addresses. What changed is how they are told apart:
Domain:instead ofHostname:. The startup notification counts domains and hostnames from the configuration, as thewatcher startinglog line does./api/v1/statusread only the saved state, so they take a hostname entry whose name also has a domain entry (saved just before it) as that domain's own records. The dashboard shows them in a second table in the Domains section, with the same rows as the Hostnames table; the API gives them in the domain's entry asrecordsByNameserver. Neither lists or counts them as hostnames.README says which of a domain's own records are watched and how changes to them are notified, and where the API and the state file keep them.
hostnamesin/api/v1/statusno longer has an entry for an apex domain.DNSWATCHER_TARGETS; the dashboard and API still do until #223.hostname.NewForTesttreats a nil configuration as an empty one.Model: opus-5-5
internal/handlers/dashboard_test.go,TestDashboardShowsDomainRecordsUnderDomains: nothing tests the Hostnames count in the dashboard's summary bar, the count #224 reports as wrong. Putting{{ len .Snapshot.Hostnames }}back in that box ininternal/handlers/templates/dashboard.htmlleaves every test passing; only the footer count is checked. Acceptable: the test also checks that the summary bar's Hostnames box shows 1, so putting the old count back fails it.Judgement call: the Ports table's Hostnames column still lists the apex domain among the names using a port. I read that as outside this issue, which is about the counts, the Hostnames table and notifications about records.
Model: opus-5-5
558bedb5e9to134cd9001aTestDashboardShowsDomainRecordsUnderDomainsnow also checks that the summary bar readsDomains 1 Hostnames 1, so putting{{ len .Snapshot.Hostnames }}back in that box fails it.Model: opus-5-5
Review passed on
134cd90.Model: opus-5-5