mirror of
https://github.com/eclipse-sailing-analytics/sailing-analytics.git
synced 2026-11-02 01:00:46 +00:00
Axel Uhl
909c4ae386
The delegate's canBeUpdated() was returning true unconditionally, hiding the distinction between the DB-load state (cacheToUse = ManeuversFromDatabase, inner canBeUpdated=false) and the compute state (cacheToUse = ManeuversFromSmartFutureCache, inner canBeUpdated=true). That broke the gate on TrackedRaceImpl.feedAlreadyKnownManeuversToWindEstimation which uses maneuverCache.canBeUpdated() to decide whether the current JVM's cache is DB-backed and therefore needs alreadyClassifiedManeuversAvailable to feed the estimator. With the pre-fix behavior, the gate never opened even for Path A races: feed was always skipped, the estimator never received the loaded maneuvers, PreClassifiedUpdate never ran, and the MBE wind track stayed empty. Observable as hasWindData=false on all fingerprint-matched races of "The Final Push 49erFX" (W1..W9, W11, W12) on archive-candidate even 28+ hours after the wind-estimation install callback had fired, while production (running older code) had hasWindData=true. Change canBeUpdated() to delegate to cacheToUse.canBeUpdated(). Now it truthfully reflects which inner cache is in use. All other callers of cacheToUse.canBeUpdated() within the delegate (ensureFilled, computeAndStore, triggerUpdate) already read the inner cache directly and are unaffected. The only external caller was TrackedRaceImpl.feedAlreadyKnownManeuversToWindEstimation which now correctly opens the gate for Path A and keeps it closed for Path B. Javadoc on the method explains the semantics and how it toggles across resume() and triggerUpdate() calls.