Reconnect inlet on settings change - #37
Merged
Merged
Conversation
`LSLInletProducer._reset_state` recreated the resolver but left `_state.inlet` (and the derived `msg_template` / `fetch_buffer` / `_warmed_up`) pointing at the previous connection. Because `_produce` only calls `_try_connect` when `_state.inlet is None`, a settings change that targeted a different stream never took effect — the inlet kept pulling the original stream (and, when the new settings reported an irregular rate, `_pull` could raise on the stale `msg_template`). Reset now tears down the existing connection and its derived state so the next `_produce` re-resolves against the updated settings. Add a regression test that connects to an 8-channel stream, pushes settings targeting a 4-channel stream, and asserts the inlet reconnects. Co-Authored-By: Claude Opus 4.8 (1M context) <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
1 participant
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.
Problem
Changing an
LSLInletUnit's settings at runtime to target a different stream had no effect — the inlet kept pulling the originally-connected stream. Surfaced while wiringLSLInletUnitinto a GUI where the user picks the stream from a menu after launch.Root cause
LSLInletProducer._reset_staterecreated theContinuousResolverbut left_state.inlet(and the derivedmsg_template/fetch_buffer/_warmed_up) pointing at the previous connection.update_settings→_request_resetcorrectly forces the next__acall__back through_reset_state, but_produceonly calls_try_connectwhen_state.inlet is None, so it never re-resolved. In the irregular-rate case it was worse: the stalemsg_template(aLinearAxistime axis) combined with the new settings'nominal_srate == 0made_pullraiseTypeErroronreplace(LinearAxis, data=…).Fix
_reset_statenow drops the existing inlet and its derived state before recreating the resolver, so the next_producere-resolves and reconnects against the updated settings.Test
Adds
test_inlet_reconnect_on_settings_change: connects to an 8-channel stream, pushes settings targeting a 4-channel stream, and asserts the inlet reconnects (channel count flips 8 → 4). Verified it fails on the old_reset_stateand passes on the new one; fulltest_inlet.pysuite passes (6 tests).🤖 Generated with Claude Code