Merge main into feature/model-selection by aws-toolkit-automation · Pull Request #574 · Amazon-Q-Developer/amazon-q-eclipse

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

aws-toolkit-automation · 2026-08-27T18:02:49Z

Automatic merge failed

Resolve conflicts and push to this PR branch.
Do not squash-merge this PR. Use the "Create a merge commit" option to do a regular merge.

Command line hint

To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):

git stash
git fetch --all
git checkout origin/feature/model-selection
git merge origin/main
git commit
git push origin HEAD:refs/heads/autoMerge/feature/model-selection

* feat: distinct sign-in error when Q Developer access is blocked Amazon Q Developer stopped accepting new Builder ID accounts. Such an account signs in successfully -- sign-in is OIDC and is never gated -- and then finds Q silently non-functional, because every Q request from that identity is refused and the refusal surfaces as if it were a chat reply. No explanation, and nothing the user can act on. Only the language server observes the refusal. The service gates on the User-Agent of the shared language server, so the plugin's own SDK calls are allowed unconditionally and there is no client-side signal to classify. The server reports it over the existing notification channel, so this change teaches the plugin to listen. - Declare aws/window/showNotification on the client and act on it. - Advertise window.notifications. Without it the runtime builds no notification router and drops the notification silently -- no error and no log, which is the failure mode that cost the most time on the VS Code and JetBrains ports. - Identify the notification by id, never by title. The runtime's router rewrites the declared id into base64 of {"serverName":...,"id":...}, so the raw id never arrives, and a title match would sign out a working user the first time an unrelated error reused the title "Amazon Q Developer". - Add QDevAccessBlockedState and resolve it in ViewRouter ahead of the logged-out state. Reacting to the refusal signs the user out, so the two states are always true together; checking logged out first would show the ordinary login view and lose the explanation. - Add QDevAccessBlockedView, following ReauthenticateView, explaining what happened, pointing to Kiro, and offering a route back to sign-in for pre-cutoff Builder IDs. The screen carries its own copy rather than displaying the service's message: that message is one sentence written for an API consumer and does not say what to do next. Consequently the dates on the screen are product copy from the public announcement, not values reported by the service. Ports the behaviour already shipped in VS Code (Amazon-Q-Developer/amazon-q-vscode#159) and JetBrains (Amazon-Q-Developer/amazon-q-jetbrains#120). Verified: mvn -B package on Corretto 17 -- BUILD SUCCESS, 508 tests, 0 failures, including 7 new classifier tests and ViewRouterTest at 14/14 with 2 new routing tests. * fix: seed the blocked state so the view router can emit at all Found in Windows testing: the Amazon Q panel rendered permanently blank. The plugin resolved and the language server launched, but no view was ever selected. ViewRouter combines its state streams with combineLatest, which emits nothing until every source has emitted once. Every pre-existing state is seeded during startup by the service that owns it, but QDevAccessBlockedState has no owning service: it is only posted when the language server reports a refusal, which for almost every user is never. The silent stream starved the combined stream, so the router never published a view and the container had nothing to render. The unit tests missed it because they hand-seed all streams. Seed NOT_BLOCKED with startWithItem at the point of combination, so the stream can never starve regardless of how the observable was injected. The clearing test now asserts the blocked -> login ordering rather than a single post, since the seed legitimately posts the login view once before the block arrives.

Uh oh!

Conversation

aws-toolkit-automation commented Aug 27, 2026

Automatic merge failed

Command line hint

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aws-toolkit-automation commented Aug 27, 2026

Automatic merge failed

Command line hint

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aws-toolkit-automation commented Aug 27, 2026

Automatic merge failed

Command line hint

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aws-toolkit-automation commented Aug 27, 2026

Automatic merge failed

Command line hint

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aws-toolkit-automation commented Aug 27, 2026

Automatic merge failed

Command line hint

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aws-toolkit-automation commented Aug 27, 2026

Automatic merge failed

Command line hint

Uh oh!

Reviewers

Assignees

Labels

Projects