fix: bound live realtimeRr, stop fabricating activity/steps for the historical record family - #21
Merged
Merged
Conversation
…he historical family realtimeRr (live.dart) accepted any positive int16 as an RR interval, unlike parseRealtimeHr and parseR24 which both gate on the 200-2500ms physiological range. A misaligned or corrupted 0x28 frame could hand an implausible beat (e.g. 5ms) straight to live HRV/breathing-coherence compute. Now bounded the same way. decodeRecord's routing for the v7/v9/v12/v18/v24 historical family hardcoded activity/steps_inc to 0 instead of null. That record family carries no IMU stepping window at all, which is the same "no usable IMU data" absence the R10 path already distinguishes from a measured zero-motion reading — this was the identical fabrication bug, just left in the block added to route those versions through parseR24. decode_parity_cases.json regenerated for the 629 cases this touches (activity/steps_inc only, hand-verified nothing else in those cases changed); ts/ is archived and was left alone.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe decoder now filters realtime R-R intervals by physiological bounds and represents unavailable IMU stepping data as null for applicable historical records. Regression tests cover both behaviors. ChangesDecoder guard corrections
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
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.
Summary
realtimeRr(live.dart) accepted any positive int16 as a beat, unlikeparseRealtimeHr/parseR24which both gate on the 200-2500ms physiological range (kMinRrMs/kMaxRrMs). A misaligned or corrupted 0x28 frame could hand an implausible RR value straight into live HRV/breathing-coherence compute (edge's_spotCheckCompute/_breathingCoherenceCompute). Now bounded the same way as the other two decoders.decodeRecord's routing for the v7/v9/v12/v18/v24 historical family (added when those versions were routed throughparseR24) hardcodedactivity/steps_incto0instead ofnull. That record family carries no IMU stepping window at all — the same "no usable IMU data" absence the R10 path already distinguishes from a genuine measured-zero reading vianull. This was the identical fabrication bug for a different code path.decode_parity_cases.json
Regenerating the second fix broke 629/2934 frozen parity cases — all exclusively on
activity/steps_inc(verified with a throwaway audit script: diffed every case field-by-field, confirmed nothing else in those 629 cases changed, and confirmed therealtimeRrbound fix caused zero fixture divergence since no existing capture has an out-of-range RR value). Patched those 629 cases' expectedactivity/steps_inctonull.ts/is archived and was intentionally left untouched.Test plan
dart test— 115 passed (was 106; added a bound-check group forrealtimeRr+ a null-activity check for the routed historical family)dart analyze— cleanSummary by CodeRabbit