Fix response routing and dedupe commands across transports
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- embedded-iot, networking
Research direction
Start with the design and open questions in the linked contracts issue 7, then trace route_responses_task and the shared TX queues in this firmware repository. Reproduce the BLE queue blocking MQTT responses and check how state updates and phone changes affect queued messages. Done means responses survive state updates, BLE disconnection does not block MQTT, messages stay with their intended phone, and duplicate pairs are suppressed across transports.
Written by the indexing model from the issue text.
Description
Part of https://github.com/OpenCarControls/contracts/issues/7, which has the design and open questions., where the audit details are.
- Responses can be evicted from the shared TX queues by state updates.
-
route_responses_taskcan stay stuck on the BLE queue with no phone connected, blocking MQTT responses. - Messages queued for one BLE phone are delivered to the next one.
- Dedupe recent (source, message_id) pairs across both transports (also covers MQTT QoS 1 redelivery).
- Dominant language
- Rust
- Stars
- 1
- Forks
- 0
- Avg merge
- 10h 56m
- Merged PRs (30d)
- 15
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenCarControls/firmware
-
Clean up E-GMP leftoversPossibly taken @Tichael claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
OpenCarControls/firmware#34 ·
Maintainers usually reply within 1 day
-
BLE: send the current state when the app subscribesPossibly taken @Tichael claimed this today. Open
Difficulty 3/5 1-2 days Newbie friendliness 35/100
OpenCarControls/firmware#58 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
OpenCarControls/firmware#55 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
OpenCarControls/firmware#54 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 55/100
OpenCarControls/firmware#53 ·
Maintainers usually reply within 1 day
All issues in OpenCarControls/firmware
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
area:sim good first issue kind:feature
Difficulty 2/5 1-3 hours Newbie friendliness 87/100
Maintainers usually reply within 1 day
-
The demo's interval button and chart legend keep the previous interval after an interval changeOpenbug ui
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
userFRM/egui-charts#670 ·
Maintainers usually reply within 1 day
-
docs good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 84/100
Usenova-Labs/usenova-backend#35 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
lugassawan/swe-workbench#823 ·
Maintainers usually reply within 1 day