mirror of
https://github.com/eclipse-sailing-analytics/sailing-analytics.git
synced 2026-11-03 09:39:38 +00:00
Axel Uhl
dc24eb05f5
The AdminConsole client reported import success before the sensor-fix import had even started. The client's completion signal is a non-null DataImportProgress result, but ImportMasterDataOperation.internalApplyTo set the result and overall progress 1.0 at the end of the object-graph apply() -- which returns to MasterDataImporter.importFromStream, where the wind-track and sensor-fix imports still run afterward. So "Done"/1.0/result fired prematurely. Move ownership of terminal completion to MasterDataImporter.importFromStream, the true end of the whole import (object graph + wind + fixes): - ImportMasterDataOperation.internalApplyTo no longer sets the result, overall 1.0, or logs "Done"; it ends at overall 0.6 and returns creationCount. - MasterDataImporter publishes the single terminal completion after the wind band (0.6->0.8) and sensor-fix band (0.8->1.0): createOrUpdateDataImportProgressWithReplication(id, 1.0, IMPORT_SENSOR_FIXES, 1.0, creationCount). The result is set only at true 1.0, with replication, so replica-polling clients observe completion correctly. - Plumb a nullable MasterDataImportObjectCreationCount through a new 5-arg createOrUpdateDataImportProgressWithReplication overload and the CreateOrUpdateDataImportProgress operation, which sets the result on replicas via progress.setResult(result) when non-null. - createOrUpdateDataImportProgressWithoutReplication now uses getDataImportLock() instead of the raw field so subclass overrides (the test mock) are honored; a no-op in production where the getter returns the field. serialVersionUIDs left unchanged: adding a nullable field is serialization- compatible and master/replicas upgrade together. Verified: MasterDataImportTest 13/13 green; both projects compile clean. Assisted-By: Claude Opus (claude-opus-5)