Repository navigation
fix(homeassistant): notify every concurrent wait - #62
Merged
Merged
Conversation
Two permission requests in quick succession produced only one notification. The tracker suppressed onWaiting whenever the session was already waiting, so the second request was tracked but never announced, and the plugin never polled for it. It stayed unanswerable even after the first was approved, because nothing announced it later either. onWaiting now fires for each distinct wait. Deduplication by request ID still applies, so a repeated event for the same ID notifies once, and the session still resumes only when every wait has cleared. Both other consumers are already idempotent: tmux-indicator returns early when active, and terminal-progress writes an unchanged escape sequence.
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.
Problem
Two
curlpermission requests arrived in quick succession, but only one notification was delivered. The one that arrived was approved correctly.Not a delivery fault this time — the tracker never announced the second request.
Root cause
wait()suppressedonWaitingwhenever the session was already waiting:So with
per_Aandper_Bin flight,per_Bgot a tracked wait but noonWaiting— no webhook, no notification, no poll. Reproduced:Worse than reported:
per_Bwas never announced even afterper_Awas approved, since nothing re-announces pending waits. It stayed unanswerable until it timed out or was answered in the TUI.The guard came from #44 to stop terminal plugins re-firing. Both current consumers are already idempotent, so it is not needed:
tmux-indicatorreturns early whenactive, andterminal-progresswrites an unchanged OSC sequence.Fix
Fire
onWaitingfor each distinct wait. Dedupe by request ID (waits.has(id)) still applies.Verification
Two distinct permissions now both notify:
Preserved invariants:
permission.askedfor the same ID → 1onWaitingper_Aonly → session stays waiting (per_Bstill pending)Real plugin, both permissions dispatched concurrently — no starvation despite
onWaitingblocking for the poll duration:Both webhooks fire immediately and both polls run concurrently.
Regression suites all pass: the five tracker scenarios (including the single-webhook guarantee for tool questions), receiver, negative-path, webhook-failure, entity-read and config harnesses.
terminal-progressemits the correct OSC sequence andtmux-indicatorstill sets/clears its flag exactly once.mise run typecheck,lint,buildpass.Note
Independent of the
0.7.5webhook-delivery work. This one explains a missing notification when the webhook itself succeeded.