mirror of
https://github.com/ipnet-mesh/meshcore-hub.git
synced 2026-07-27 20:12:57 +02:00
Louis King
e93c7fd9d6
Reported symptom: user edits a Route (e.g. lowers packet_count_threshold from 6 to 3), and the routes list card still shows the old threshold for ~30s. The cache stack was exonerated — x-cache: MISS on the stale GET, response body had the new packet_count_threshold=3, but route_result. threshold remained at 6. Root cause was neither HTTP cache nor Redis cache. The list card's stats row (renderStatsRow in routes.js:82) displays route_result.threshold / effective_clear / matched_count, which are persisted by the background route_evaluator on a 30-60s schedule — separate DB row from the route's direct fields. The PUT handler updated the route row immediately but never triggered a re-evaluation, so route_result carried the stale snapshot from the prior evaluator cycle until the next sweep. Fix: add _reevaluate_route(session, route) helper that runs evaluate_route + upsert_route_result synchronously after the route commit. Called from create_route (initial evaluation) and update_route (refresh on every config change). Disabled routes short-circuit (no point evaluating a route that's turned off). One bounded DB scan per write — same cost as a single-route evaluator tick. After this fix, the PUT response itself carries a fresh route_result reflecting the new packet_count_threshold / clear_threshold, and the next GET /api/v1/routes returns it. The list card updates on the very next render cycle. Tests: - test_update_threshold_immediately_reflects_in_route_result: seeds a stale RouteResult with the OLD threshold, sends a PUT, asserts the response's route_result.threshold/effective_clear now match the new route config. - test_disabled_route_does_not_trigger_evaluation: monkeypatches evaluate_route to a spy, asserts it's never called for disabled routes.