fix(Label_QQ): guard groundspeed on the actual 45..48 field, not remaining.text - #512
fix(Label_QQ): guard groundspeed on the actual 45..48 field, not remaining.text#512fuleinist wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughLabel QQ groundspeed decoding now checks the extracted groundspeed field. A regression test covers a populated preceding field followed by the ChangesLabel QQ groundspeed decoding
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
🟢 Ready to approve
The fix addresses the documented NaN bug and adds a targeted regression test; remaining feedback is a minor test assertion/type-safety cleanup.
This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.
Pull request overview
Fixes Label_QQ.decode() groundspeed decoding so the --- placeholder is detected on the actual groundspeed field (45..48), preventing Number('---') from producing a NaN groundspeed and "NaN knots" output.
Changes:
- Read groundspeed into a local
gsFieldand guard decoding ongsField !== '---'(while preserving the existingremaining.text !== '---'behavior). - Add a regression test covering the
028---split case to ensure groundspeed is not decoded and is recorded as unknown.
File summaries
| File | Description |
|---|---|
| lib/plugins/Label_QQ.ts | Fix groundspeed placeholder guarding by checking the 45..48 groundspeed field directly. |
| lib/plugins/Label_QQ.test.ts | Add regression coverage for the 028--- case (non-placeholder 42..45 followed by placeholder groundspeed). |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Lite
We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.
| expect(decodeResult.raw.groundspeed).toBeUndefined(); | ||
| expect(Number.isNaN(decodeResult.raw.groundspeed)).toBe(false); |
Fixes #507.
Problem
Label_QQ.decode()guards the groundspeed field by testingdecodeResult.remaining.text !== '---', but at that pointremaining.textholds the previous unknown field (substring(42, 45)), not the groundspeed field (substring(45, 48)). When 45..48 is---but 42..45 is not (e.g....028---0009), the guard passes andNumber('---')stores aNaNgroundspeed, rendering"NaN knots".Fix
Read the groundspeed field into a local (
gsField) and include it in the guard:Note: I intentionally kept the existing
remaining.textcheck rather than replacing it with a check ongsFieldalone. The variant 2 fixture (...10.1---0200009) asserts that when the 42..45 field is---, the following020is recorded as unknown rather than decoded as a 20-knot groundspeed. Guarding ongsFieldalone would change that established behavior; this version preserves both existing fixtures while eliminating the NaN path.Tests
028---split: nogroundspeedinraw, noGSPDformatted item, field recorded as unknown.Summary by CodeRabbit
Bug Fixes
Tests