fix(apple-health): take a percent from a fraction or an already-scaled client - #1000
Merged
Merged
Conversation
…d client 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
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Oxygen saturation and body fat never reach the server from the iOS app: the app scales them by 100 before upload, the importer scales again, the plausibility guard rejects the row as out of range inside a 200, and the client treats that skip as final and advances its HealthKit anchor. The reading stays on the phone and is never retried. Reported with a full cross-repo trace in MBombeck/healthlog-iOS#7.
The contract says values travel raw and the server scales them, which is what the OpenAPI description publishes. One comment in
prisma/schema.prismasaid the opposite; that is the line the app was built against, and it is corrected here.The five percent-shaped HealthKit identifiers now accept either spelling, so current App Store builds stop losing readings without waiting for an app release. The range guard still rejects an impossible value either way.
Note for review:
waistCircumferenceuses the same x100 to convert metres to centimetres. A blanket change turned a 1.02 m waist into 1.02 cm, so a test now pins the tolerant converter to the percent class and to nothing else.