Repository navigation
Resolve blocked_on against a card alias (v0.9.1) - #18
Merged
Merged
Conversation
Found by driving the full scenario through a real dsh host rather than a test. The docs session declared itself blocked on "checkout-client" — the alias that session publishes about itself — and resolution did not recognise it, because it matched only folded display names and session ids. The alias was stored verbatim, so the wait chain ended at a session that does not exist and a genuine mutual wait went undetected. The model noticed the deadlock in prose and the tool did not, which is the wrong way round. An alias is the handle a session publishes about itself, and therefore the one a peer reads and repeats. Every resolution path has to honour it: this is the same root cause as the group-lead defect fixed in v0.5.0, in the one place that fix did not reach. Aliases are now checked first, before names and ids. The regression test pins the failure rather than the fix: two sessions blocked on each other, one storing a name instead of an id, must produce no cycle — and the same pair with the id resolved must produce one. That keeps the test honest about what actually breaks. Re-run live against the fix: peer_status reported the full cycle at the moment it closed. 327 tests. Version 0.9.1.
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
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.
Found by driving the whole scenario through a real
dsh webhost with real models, which is the only place it could have been found.What happened
The docs session declared itself blocked on
"checkout-client"— the alias that session publishes about itself. Resolution matched only folded display names and session ids, so the alias was stored verbatim:The wait chain dead-ended at a session that does not exist, so a genuine mutual wait went undetected. The model noticed the deadlock in prose and the tool did not — exactly the wrong way round.
Root cause
Same as the group-lead defect fixed in v0.5.0, in the one place that fix didn't reach. An alias is the handle a session publishes about itself, so it's the one a peer reads and repeats. Every resolution path has to honour it. Aliases are now checked first, before names and ids.
The test pins the failure, not the fix
Two sessions blocked on each other with one storing a name instead of an id must produce no cycle; the same pair with the id resolved must produce one. Asserting the broken shape keeps the test honest about what actually breaks.
Verified live, after the fix
The full run
Four sessions, real models, real files. It produced the same numbers the deterministic scenario test predicts:
Plus a fourth session told nothing about the history, which found the deferral in the ledger and declined to reopen it.
327 tests.