Files
Northern-Thailand-Ping-Rive…/tests
grabowski 7e64e0cf18
CI/CD Pipeline - Northern Thailand Ping River Monitor / Test Suite (3.11) (push) Failing after 29s
CI/CD Pipeline - Northern Thailand Ping River Monitor / Build Docker Image (push) Skipped
CI/CD Pipeline - Northern Thailand Ping River Monitor / Integration Test with Services (push) Skipped
CI/CD Pipeline - Northern Thailand Ping River Monitor / Deploy to Staging (push) Skipped
CI/CD Pipeline - Northern Thailand Ping River Monitor / Deploy to Production (push) Skipped
CI/CD Pipeline - Northern Thailand Ping River Monitor / Performance Test (push) Skipped
CI/CD Pipeline - Northern Thailand Ping River Monitor / Code Quality (push) Successful in 18s
CI/CD Pipeline - Northern Thailand Ping River Monitor / Cleanup (push) Successful in 1s
fix: one current river level, not two
The verdict banner and the P.1 outlook each wrote state.p1Now from a
different feed — the banner from the latest measurement, the outlook from
current_level on the forecast rows, which carries whatever the model saw
at its as_of. Forecasts are precomputed hourly, so the two drifted apart:
production showed 1.66 m in the banner and 1.52 m in the outlook directly
below it. Harmless at low water; at flood stage two contradictory river
levels on one screen undermine the warning.

setP1Level() now arbitrates: freshest timestamp wins, and the replay and
demo hooks pass force since they deliberately pin a level that is not the
live one. The outlook renders the arbitrated value and clamps the shown
peak to at least the current level, so a stale forecast can no longer
predict a peak below where the river already is. endReplay drops the
replayed level so live data re-arbitrates cleanly.

Verified against a stub reproducing the exact production conditions
(gauge 1.66 at 08:35 vs forecast 1.52 at 08:00): both now read 1.66; a
2.50 m rise against a stale 1.81 m peak renders 2.50/2.50; the 2024
replay still tracks its frames and returns to live on stop.
2026-08-14 09:25:39 +07:00
..