fix: first-run wizard reappears after setup (configured latch + serialized settings writes)#38
Merged
Merged
Conversation
…ites The first-run wizard could reappear after setup was already done. Two independent causes, both fixed here: - `configured` was recomputed live on every destination toggle/delete, so disabling or deleting the last enabled + well-formed destination flipped it back to false and reopened the wizard. It is now a one-way first-run latch, cleared only by an explicit full reset. Extracted the "ready to stream" condition into a tested `has_streamable_dest`. - Every settings handler did an unsynchronized clone -> mutate -> send() of the whole Settings struct, so two overlapping POSTs lost one update (which could resurrect a stale configured=false). All settings mutations now serialize through one process-wide write lock (SETTINGS_WRITE_LOCK). Adds latch + streamable-dest regression tests (238 passing). README test count refreshed. Reported by fashionxd.
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.
Summary
The first-run wizard could reappear after setup was already complete. Reported by fashionxd. Two independent root causes, both fixed:
Semantic (the reproducible one).
configuredwas recomputed live on every destination toggle/delete as "is any destination streamable right now." So disabling or deleting your last enabled + well-formed destination flippedconfigured=falseand reopened the wizard on next load. The 0.1.10 dock's one-tap destination toggle made this easy to hit for single-destination users. It is now a one-way first-run latch, cleared only by an explicit full reset (scope=all). The "ready to stream" condition is extracted into a testedhas_streamable_dest.Race (secondary). Every settings handler did an unsynchronized
settings.borrow().clone()-> mutate ->send(whole_struct), one task per connection. Two overlapping POSTs lost one update, which could resurrect a staleconfigured=false. All 12 settings mutators now serialize through a single process-wideSETTINGS_WRITE_LOCK(astd::sync::Mutex; the critical section never.awaits, and its!Sendguard makes that a compile-time guarantee). This closes the lost-update race for every settings field, not just this flag.Behavior change
Removing/disabling your last destination now leaves you on the dashboard (empty Destinations state) instead of reopening the wizard. "Reset everything" still returns to the wizard.
Verification
cargo fmt,cargo clippy --releaseclean,cargo test --release238 passed (+2 regression tests pinning the latch contract).