Repository navigation
fix: say an unsaved VS Code revocation lasts until the broker window closes - #1485
Merged
Merged
Conversation
…closes VS Code runs BurrowService only in the broker window, so a revocation whose ACL save failed is lost when that window closes and the next broker loads the stored ACL. The error and the spec said it lasted until Dormouse quits, which holds only for standalone. Refs #1484
Deploying mouseterm with
|
| Latest commit: |
341cff9
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://025e16af.mouseterm.pages.dev |
| Branch Preview URL: | https://fix-issue-1484.mouseterm.pages.dev |
dormouse-bot
commented
Oct 31, 2026
dormouse-bot
left a comment
Collaborator
Author
There was a problem hiding this comment.
Argos (argos/storybook-chromium, argos/storybook-webkit) is red: each reports "1 changed — waiting for your decision". This PR can't produce a screenshot diff, because it changes only the text of an error thrown when a revocation save fails, plus a doc comment, a test, and spec prose. The open #1483 shows the same single change on both browsers, which points to a baseline that drifted rather than this diff. Accepting the change in Argos should clear the status. I found nothing else to raise in the code or the spec edits.
This was referenced Oct 31, 2026
`PairedPhonesAndAccessLog` built its log in a `parameters` literal, which runs at module load, before the meta's `beforeEach` pins `Date.now` to `STORY_NOW`. The log therefore carried the CI runner's wall-clock time, and every PR showed an Argos diff on `modals-remotecontrolsection--paired-phones-and-access-log`. `pairedDevices` and `accessLogEntries` now take an optional `now`, and the story passes `STORY_NOW`; `OneTimeEndedNetworkNotAllowed`'s refusal time gets the same treatment. Co-Authored-By: Claude Opus 5.5 <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
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.
VS Code runs
BurrowServiceonly in the broker window, and a revocation whose ACL save failed is held only in that service's memory (#unsavedRevocations). When the broker window closes, the next broker loads the stored ACL, which never got the revocation, so the phone is paired again. The error andremote-security-model.md→ "Revocation" both said the refusal lasts "until Dormouse quits". That is true only for standalone.This PR takes the "narrow the promise" option from #1484. The error now picks its wording from the service's
kind: VS Code says "refused until the window running remote control closes", and standalone keeps "until Dormouse quits". The spec sentence, its rationale entry, and the field comment now say the hold ends when the service stops, and name both cases. The existing failed-save test runs asvscodeand fails on the old text. A new test pins the standalone wording.The other option is still open: pass pending revocations to the next broker so the original promise holds. That is a larger change, and this PR doesn't rule it out.
Refs #1484 — automated triage