Fixed: heartbeat ping history is back

A short, honest note about a bug we fixed.

What was broken

The “Ping arrivals” block in the heartbeat monitor card showed “Failed to load ping history” — the history request consistently failed with a 500 error. Monitoring itself worked fine: pings were accepted, counters and the pending / up / down statuses kept updating. Only the journal was down.

Why

A classic bug at the boundary between two layers. The source IP of each ping is stored in a PostgreSQL INET column, and the database driver returns such values as specialized Python objects rather than strings. The API response schema expected a string, the object failed validation — and the request crashed. Since an IP is recorded with every single ping, every journal page of every monitor was affected.

The fix

The driver is now configured to return network types as plain strings across the whole application — this fixes the journal itself and a couple of neighboring spots with the same latent pattern that hadn’t fired yet. The behavior is pinned by regression tests against a real database, so this class of bug can no longer slip past CI.

The important part: your data is intact

Ping ingestion never depended on the broken read path — the full history was being recorded the whole time. After the update, the journal shows your accumulated pings retroactively: start / success / fail signals, job durations, source IPs, and the message field from ping bodies — the one that previously had nowhere to be seen.

Thanks to the user who sent a detailed bug report with a request_id and reproduction steps — with a description like that, diagnosis took minutes. If something looks off, the feedback widget is there and it works.