HydraIssues

hydratam v0.1.1 is live and serving. Deployment record.

Admin token is in /srv/scales/hydratam/config.yaml on the node.

Why pi-node-001

7 GB free against 3 GB on 003 and 004, load 0.00, 6 scales against 8 and 11, and hydraskin v0.13.0 (003 is on v0.11.0, 004 on v0.12.0). Host port 30000 was free there.

Verified in production

• HTTPS 200 with a valid certificate, 102 ms.
• 15 markets, 32 NUTS 2 regions, 47 cities, 3 live venues.
• Tier counts 1/2/3/5 plus 4 unranked.
• GET /api/v1/regions/DE12 resolves to baden-wuerttemberg, Flagship fit. NL33 (retired) 404s. Lowercase nl36 resolves to zuid-holland.
• Writes 401 without a token, reads 200.
• Atlas renders from the live API in a headless browser: 276 regions drawn, 32 targets, 44 city markers, 3 venue markers.
• Runbook served at /api/v1/runbook.
• State persisted to the host disk, so it survives a container recreate.

Coverage confirms #621

The optional hydradistrict integration reaches the service, finds 6 districts and 0 with coordinates:

{"district_count":0,"districts_total":6,
 "warning":"none of the 6 districts in hydradistrict carry coordinates, so no distance can be measured..."}

The atlas hides the district layer rather than failing. Distances start working the moment #621 is backfilled, with no hydratam change.

Two things worth recording

A health endpoint that called another service. /api/v1/health called Coverage.Snapshot synchronously, so a health request could block on up to seven sequential calls to hydradistrict, ten seconds each on timeout. The router health-checks this service, so a hydradistrict outage would have 503'd hydratam.experiencenet.com for a reason that has nothing to do with hydratam. Fixed in v0.1.1: health reads cache only and reports districts_probed false until something asks for a distance. The test was checked against the old code to confirm it fails there rather than passing vacuously. Same failure shape the cutover runbook warns about for health_path.

The registry token secret. Copying hydradistrict's SCALE_REGISTRY_TOKEN would have failed: the fleet token rotated 2026-08-28 and hydradistrict's secret dates from 2026-07-29. The current value was read from /etc/hydrascaleregistry/config.yaml on the registry host. Other repos with secrets set before that date are still stale.

Open

• Tier the 4 unranked markets or drop them (#603).
• Narrow the NUTS 1 targets to the specific NUTS 2 regions wanted.
• Backfill district coordinates (#621) to switch coverage on.
• Replace the seeded venues with the live hydravenues feed.

Update 2026-08-31: v0.1.2

The bare domain returned the JSON service descriptor, which a browser renders in its own pretty-printer. Someone opening hydratam.experiencenet.com wants the map.

GET / now content-negotiates: an Accept containing text/html gets the atlas, curl's / and an explicit application/json still get the descriptor. Verified in production: browser Accept returns text/html 37568 bytes, curl returns the descriptor, and a headless render of the bare domain draws 276 regions with 32 targets.

It serves the page rather than redirecting, deliberately. A 30x on / is a known trap on this fleet: the router health-checks / whenever user.hydra.health_path is missing, and a redirect there marks the service down and 503s its domain. hydramirror and hydraapplepipeline both hit it. Answering 200 with the page keeps that impossible even if the label is ever lost.

Rolled out with hydraskin update hydratam --tag v0.1.2 --apply, 12 seconds, rollback target v0.1.1. State survived the container rebuild: still 15 markets, 32 regions, 47 cities, 3 venues.