mirror of
https://github.com/eclipse-sailing-analytics/sailing-analytics.git
synced 2026-11-02 01:00:46 +00:00
Axel Uhl
165bc8f304
Restores the compute-path guard on feedAlreadyKnownManeuversToWindEstimation. Without the gate, setWindEstimation submits per-competitor feed tasks that call maneuverCache.get(waitForLatest=true) concurrently with the ordinary detector-driven feed via newManeuverSpotsDetected. Depending on ordering the feed task either sees the recalculation already in progress (blocks, then double-feeds via alreadyClassifiedManeuversAvailable, whose per-competitor PreClassifiedUpdate reconciliation clobbers the graph path's whole-race track) or completes before the trigger fires (get returns null, feed skips). The double-feed shows up as flakiness of IncrementalMstHmmWindEstimationForTrackedRaceTest -- observed locally with a ratio-of-matching-fixes of 0.658 vs the 0.75 threshold, and also seen on GitHub Actions run 30262443673. The rationale for removing the gate previously (that after the bug6241 polar-data hold-back the estimator may be installed after detection ran with a null WindEstimationInteraction) is now handled explicitly by the retype-and-store choreography in ManeuverCacheDelegate.computeAndStore: its runWhenWindEstimationInstalled callback re-drives the detector once the estimator is in place, and freshly built detectors (whose per-competitor cache was cleared by updateManeuversAndWindWithNewWindEstimation at install time) emit spots through the graph path with cross-competitor aggregation intact -- no per-competitor slice ever needed. Adds a substantial comment on the method spelling out why the gate must stay in place, so future edits don't remove it again.