mirror of
https://github.com/okieselbach/AutopilotMonitor.git
synced 2026-10-24 12:42:38 +00:00
066b6e6f04
Measured over 14 days, GET health/mcp answered in 4..148ms when warm and timed out at 30s in 50 of 83 calls — the median call took 27,972ms. A cold start is 20-30s of Container Apps activation (~98% KEDA plus image mount, ~500ms application), so no UI wait covers it and the generous timeout only bought a long wall in front of the same answer. The browser's own budget is the same 30s, so the backend's carefully worded warning never reached the user at all: they saw a raw DOMException. Backend: the budget drops to 3s, which sits in the widest observed latency gap (2347ms..3930ms) so jitter cannot flip the verdict. Our own cancellation now reports the new status "warming" at Information level (with minReplicas=0 a cold probe is the expected path, and logging it as a warning poisons the ops signal); HttpRequestException is split out of that catch and stays a real warning, still without the host in the message. The warm-hit threshold drops to 750ms — ~5x the warm maximum, deliberately generous because every measurement comes from a near-idle single-user system and warm latency will rise under concurrency — and moves into McpReachableMessage so a test can pin the boundary. The XML doc now describes the probe that exists rather than the wake-signal design the measurements disproved. "warming" is a new status value rather than an added DTO boolean because the backend deploys before the web: an unknown value degrades to a grey card with a clean banner, whereas a boolean would leave old web showing yellow and "Warnings detected" on every cold start. HealthCheck.Status now documents the five-value vocabulary, which rides into both generated TypeScript mirrors as JSDoc. Web: resolveMcpCardState owns display, banner rating and the poll decision as a pure function (the suite runs on node, so testable logic cannot live in JSX). A warming server re-probes every 5s for up to 8 attempts and stays out of the overall banner exactly as "unknown" already does — scaling from zero is expected behaviour, not a degraded platform — and only becomes a real warning once the re-polls are spent. The card keeps showing "warming" while the next probe is in flight so it cannot flicker, carries the blue in-progress look instead of yellow, and was hoisted out of the healthResult guard: a failing detailed check would otherwise hide a card that is still polling. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>