Repository navigation
gate battery pack info reply on gen5 cmd_status - #57
Conversation
was decoding a full-length reply body without checking status, so a gen5 failure/deferred reply with a stale but 30-byte body would still produce a confident BatteryPackInfoResponse. gen4 stays ungated since its status byte is unconfirmed, same reasoning as getClock/getDataRange.
|
Warning Review limit reachedNext included review available in 34 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
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.
Sorry @abdulsaheel, you've used your own review budget of 250,000 diff characters for the last 7 days.
You can request another review in 6 days and 18 hours by commenting @sourcery-ai review. Upgrade to get a review now.
Reviewer's GuideThe PR aligns battery pack info parsing with the existing gen5 status-gating convention: successful gen5 replies are decoded, failed/deferred replies are discarded, and gen4 remains ungated. Tests cover both gen5 outcomes. Flow diagram for battery pack info status gatingflowchart TD
A[parseCommandResponse receives battery pack info] --> B{profile.isGen5}
B -->|No| C[Decode BatteryPackInfoResponse]
B -->|Yes| D{status == 1}
D -->|Yes| C
D -->|No| E[Discard battery pack info reply]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
getBatteryPackInfo was the one battery-adjacent reply in this file with no status gate. getClock/getDataRange/getBatteryLevel(gen5)/getHello(gen5) all check cmd_status==1 on gen5 before trusting the body, this one didn't, so a gen5 failure/deferred reply with a stale-but-full-length body would still decode into a confident attached/mac/name/type.
fix mirrors the existing convention exactly:
statusOk = !profile.isGen5 || status == 1, gen4 stays ungated (status byte unconfirmed there per the comment above getClock).added two tests: gen5 success still decodes, gen5 cmd_status=0 gets dropped. existing gen4 success test untouched.
dart test: 617 passed, 4 skipped, 0 failed.Summary by Sourcery
Gate gen5 battery pack information decoding on a successful command status while preserving existing gen4 behavior.
Bug Fixes:
Tests: