fix(amazonq): declare serverInfo so notifications reach the client

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.

[ashishrp-aws]

Targets feature/qdev-signup-message, same as #2794 and #2796.

Problem

After #2796 the notification still never reached the client. The runtime only constructs a notification router for servers that declare serverInfo:

if(initializeResult?.serverInfo){this.notificationRouter=newRouterByServerName(initializeResult.serverInfo.name,this.encoding)}

AmazonQServiceServer's initializer returned only capabilities and awsServerCapabilities, so no router was built and showNotification took this branch:

if(!this.notificationRouter){this.logger.log(`Notifications are not supported: serverInfo is not defined`)}this.notificationRouter?.send(...)// no-op

Observed in VS Code against prod RTS with a blocked Builder ID — the block was detected and logged, then silently discarded:

[Warn] lserver: Q Developer plugin access is blocked for this identity: Please visit https://kiro.dev/ ...
lserver: Notifications are not supported: serverInfo is not defined

Two servers in this repo already do this correctly (aws-lsp-identity, aws-lsp-notification); this follows their convention.

Why it took three PRs

Each layer failed silently and independently:

PR	Layer	Failure mode
#2794	detect the denial	worked
#2796	pass notification to the service manager	optional feature, so omitting it compiled and disabled reporting
this	declare serverInfo	no router, so showNotification is a no-op

Nothing threw at any layer. Worth considering whether showNotification should warn rather than log when it drops a notification — a server author has no way to notice today. Happy to raise that against the runtime separately.

Testing

• Regression test added asserting the initializer returns serverInfo. The failure mode is silent, so without a test this regresses invisibly.
• The name is asserted exactly, deliberately: RouterByServerName encodes it into the id of every notification the client echoes back, so renaming it strands followups for notifications already on screen.
• tsc --noEmit clean, prettier clean, eslint clean (0 errors).
• Verified end-to-end in VS Code with a server bundle built from this branch installed into the resolved flare directory.

Pre-existing failure, not from this change:amazonQServer.test.ts → "hooks onUpdateConfiguration handler to LSP server" fails on this branch before my change (6 passing/1 failing before, 7/1 after). Left alone as unrelated, but it should be looked at.

Correction to #2796

I claimed there that clients could match on id === 'qDevPluginAccessBlocked'. That is wrong. RouterByServerName.send() replaces the id with base64 of {"serverName":...,"id":...} before it reaches the client, so the raw string never arrives. id is the runtime's followup-routing token, not a semantic identifier. The id is still worth keeping (it is what makes followups routable), but clients cannot match on it as a plain string — both IDE clients currently identify the notification by title, and I'll follow up on a durable way to identify it.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 63.76812% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.30%. Comparing base (b0018f8) to head (c55b330).

Files with missing lines	Patch %	Lines
...codewhisperer/src/shared/streamingClientService.ts	58.82%	14 Missing ⚠️
.../aws-lsp-codewhisperer/src/shared/amazonQServer.ts	0.00%	8 Missing ⚠️
...mazonQServiceManager/AmazonQTokenServiceManager.ts	88.88%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## feature/qdev-signup-message #2797 +/- ##
===============================================================
+ Coverage 60.47% 62.30% +1.83% 
===============================================================
Files 282 282 Lines 71465 71530 +65 Branches 4608 4827 +219 ===============================================================
+ Hits 43218 44570 +1352 + Misses 28158 26868 -1290 - Partials 89 92 +3 

Flag	Coverage Δ
unittests	62.30% <63.76%> (+1.83%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ashishrp-aws]

Added a second commit: fix(amazonq): observe access-blocked on the streaming client too.

Why. The observer from #2794 was only on the token client. Chat runs through the streaming client, so the one surface where a blocked identity actually shows up to the user was the one place nothing was watching. Detection worked anyway only because the gate denies every operation and the A/B config fetch goes through the token client moments after credentials arrive — incidental, not a guarantee.

What. Mirrors the token client exactly: middleware on the outermost initialize step (fires once per operation after retries, not per attempt), observer called inside its own try/catch, error always rethrown so callers are unaffected.

Notifier lifetime. The notifier is now created once per service generation and shared by the token and streaming clients rather than created per client. It dedupes per instance, so sharing is what keeps a blocked identity to a single notification regardless of which client observes it first. It is cleared in resetCodewhispererService, so signing out and back in with another blocked identity notifies again instead of being suppressed.

Scope.StreamingClientServiceToken only. The IAM variant serves a different surface, and the gate only denies Builder ID, which is bearer-token only.

Tests. Added one asserting the streaming client receives an observer — previously undefined, which is the gap. Reference-equality against the token client is not assertable in that harness because the token service is a sinon stub, so the test asserts only the streaming side.

Pre-existing failures on this branch, unchanged by either commit (verified by stashing and re-running): utils.test.ts 11 failing / 89 passing, and amazonQServer.test.ts 1 failing. Both identical before and after.