mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-09 13:01:00 +00:00
Marc-André Bombeck
9d9e8570f7
Shipped iOS builds multiply oxygen saturation and body fat by 100 before upload. The importer scaled them again, so 0.97 was stored as 9700, the plausibility guard rejected the row as out of range inside an HTTP 200, and the client treats that skip as final and moves its HealthKit anchor past the sample. Every reading of those two types was lost, silently, on every install that syncs them. The contract says values travel raw and the server scales, and that is what the OpenAPI description publishes. One comment in the schema said the opposite, that the client must multiply by 100 first, and that is the line the app was built against. It is corrected here. The five percent-shaped HealthKit identifiers now take either spelling: a value above the fraction ceiling is already a percent and passes through, anything at or below it is scaled. The domains do not overlap, and the per-type range guard still rejects what is impossible either way. Current app builds stop losing readings without an app release. The tests pin both spellings, the range after conversion, and that the tolerant converter covers the percent class and nothing else: waist circumference uses the same factor to turn metres into centimetres, and a blanket change made a 1.02 m waist into 1.02 cm. Refs MBombeck/healthlog-iOS#7