Repository navigation
Resynchronise after a stale LUBA transmit confirmation - #163
Merged
Merged
Conversation
A weak bus can let a frame's "sent" confirmation arrive after its send has already timed out, leaving it queued ahead of the next send's own. The next send then matched the stale confirmation, and every later send inherited the one-off mismatch, so the whole stream stayed desynchronised. Sends are serialised under the transmit lock, so a confirmation for a different frame can only be such a leftover; discard it and keep waiting for this frame's own confirmation, letting the stream resynchronise. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
2 participants
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
On the Lunatone LUBA RS232 driver (DriverLubaRs232), a weak/busy bus can deliver a frame's "sent" confirmation after that send has already timed out. The late confirmation stays queued on _queue_tx_conf ahead of the next send's own confirmation. The next send then consumes the stale one, and because it never sees its own, every subsequent send inherits the same one-frame offset — the confirmation stream stays permanently desynchronised until the driver is restarted.
Fix
When the confirmation being awaited is for a different frame than the one just sent, discard it and keep waiting for the matching one. This is safe because sends are serialised under _tx_lock: nothing later is in flight yet, so a mismatched confirmation can only be a leftover from an earlier, already-timed-out send. The previous code logged this mismatch as an error and returned, which is exactly what left the stream offset.
The change is confined to the confirmation-matching branch in DriverLubaRs232.send_dali_command; the happy-path trace log is preserved, and a genuine error_code still raises TransmissionError as before.
Testing
New test_send_dali_command_resyncs_after_stale_confirmation queues a stale confirmation ahead of the real one and asserts the send drains both, recovers, and warns.
Full serial-driver suite passes (pytest dali/tests/test_serial_driver.py, 10 passed).