Merge master into feature/toolkitOnly #8525
Open
Conversation
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
## Problem - workspace connection is currently failing via presigned url due to change of attributes ## Solution - reverting change and using eks cluster attr for hostname ## Testing - updated unit tests - tested locally with new vsix --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license.
…#8514) ## Problem Console session credentials fail to work properly in two scenarios: 1. After token refresh or profile overwrite: Users encounter "Your session has expired" errors even after successfully running aws login, requiring manual VS Code restart without clear guidance (reported in #8488) 2. Immediate connection use after CLI login: When users try to use a connection immediately after aws login completes, the credential provider was created before the CLI wrote the new login session to disk, causing authentication failures ## Solution - Enhanced makeConsoleSessionCredentialsProvider() to detect stale credential scenarios and prompt for window reload <img width="1409" height="939" alt="final-2-after-succeeds" src="https://github.com/user-attachments/assets/2c0b77be-ea10-4a41-9642-29d637a03110" /> - Added user-friendly messages showing identity ARN after successful login <img width="1408" height="941" alt="final-1-before-retry" src="https://github.com/user-attachments/assets/841721be-525d-4853-8d7a-b49f7d97c272" /> - Improved inline documentation explaining AWS CLI vs SDK credential handling differences - Added handling for does not contain login_session error when provider is created too early - Removed try-catch wrapper when verifying that connection exists after CLI succeeds ## Tradeoffs Reloading the VS Code window is a heavier UX, but it is the only deterministic way to fully reinitialize credential providers and avoid using stale credentials. Reloading guarantees that all in0memory credential providers, Auth state, and AWS SDK clients are fully reinitialized. This avoids subtle, hard-to-debug states where credentials appear refreshed on disk but stale credentials are still used at runtime. The reload is user-initiated via confirmation, not automatic. For future direction, this needs a supported Auth/provider reset mechanism to refresh credentials without requiring a window reload. ## Testing 1. Run `npm run compile` to verify build. 2. Run `npm run package`. Manual verification of end-to-end flow - Verified token refresh flow prompts for reload and works after reload - Tested immediate connection use after aws login triggers appropriate reload prompt - Confirmed profile overwrite scenarios handle credential refresh correctly --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license.
## Problem - This setting is no longer used. <img width="1276" height="242" alt="image" src="https://github.com/user-attachments/assets/71c2a761-e849-4058-ac99-41329cd32c28" /> ## Solution - Removing /dev amazonq settings --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license.
This merges the released changes for rc-20260122 into main. MCM-XXX --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license. --------- Co-authored-by: aws-toolkit-automation <>
## Problem
After updating AWS CLI for console credentials, the success message
didn't show users which AWS CLI installation the Toolkit was actually
using. This made it unclear whether the update was successful or if
multiple CLI installations existed on the system.
This is particularly problematic for users who encountered repeated
update prompts during console credentials authentication, as they can't
verify if the correct CLI version is being used.
## Solution
- Added child process execution to run the OS-specific command (which on
Unix/macOS, where on Windows) after CLI update
- Retrieved the actual AWS CLI path that the Toolkit uses for console
credentials
- Updated the success message to display: 'AWS CLI updated successfully
to "{path}"'
This helps users immediately verify the CLI installation location and
confirms which CLI binary the Toolkit will use for console login.
### Notes
We make a display message clearer that this is about what the Toolkit
will be used going forward, not necessarily what the installer was just
installed. This helps distinguish between:
- What the installer just updated/installed
- What the Toolkit will actually use (which could be a different
installation if multiple exist)
<img width="1197" height="800" alt="cli-1-detect-need-to-update"
src="https://github.com/user-attachments/assets/f728cec2-7428-4b86-9b65-a06007a248da"
/>
<img width="1199" height="795" alt="cli-2-installer-proceeds"
src="https://github.com/user-attachments/assets/792438b6-9fae-49e7-bbd1-8c52d4a7f414"
/>
<img width="1197" height="799" alt="cli-3-show-path-in-message"
src="https://github.com/user-attachments/assets/3bf6957f-f13f-4c33-a5e3-c0515a0e173c"
/>
---
- Treat all work as PUBLIC. Private `feature/x` branches will not be
squash-merged at release time.
- Your code changes must meet the guidelines in
[CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines).
- License: I confirm that my contribution is made under the terms of the
Apache 2.0 license.
---------
Co-authored-by: invictus <[email protected]>
… adding region to profile (#8522) ## Problem - If a user picks a profile that does not have region entry from the config file, smus tries to update the profile with selected region. But smus is only looking for the profile in credentials file. ## Solution - Look for profile in both config and credentials files when adding region to profile - Use shared parsing method to handle profiles with `profile` prefix ## Test Updating profile with `profile` prefix in config file before ``` [profile configWithProfilePrefix] AWS_ACCESS_KEY_ID=xyz AWS_SECRET_ACCESS_KEY=xyz AWS_SESSION_TOKEN=xyz ``` after ``` [profile configWithProfilePrefix] AWS_ACCESS_KEY_ID=xyz AWS_SECRET_ACCESS_KEY=xyz AWS_SESSION_TOKEN=xyz region = ap-east-1 ``` --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license. Co-authored-by: kzr-at-amazon <[email protected]> Co-authored-by: invictus <[email protected]>
## Problem Toolkit is using an older Lambda SDK (3.731, latest 3.9xx) due to compatibility issues. This caused new fields introduced in LMI/DAR to be not available in local types and need to be manually bypassed. see: #8392, we need to update lambda SDK to latest version and resolve all the compatibility issues Below is the compatibility issue when trying to upgrade sdk lambda client ``` npm error src/shared/clients/lambdaClient.ts(327,9): error TS2741: Property 'config' is missing in type 'AwsClient' but required in type 'LambdaClient'. npm error src/shared/clients/lambdaClient.ts(328,13): error TS2419: Types of construct signatures are incompatible. npm error Type 'new (...[configuration]: [] | [LambdaClientConfig]) => LambdaClient' is not assignable to type 'new (o: AwsClientOptions) => AwsClient'. npm error Construct signature return types 'LambdaClient' and 'AwsClient' are incompatible. npm error The types of 'middlewareStack.add' are incompatible between these types. npm error Type '{ (middleware: InitializeMiddleware<ServiceInputTypes, ServiceOutputTypes>, options?: (InitializeHandlerOptions & AbsoluteLocation) | undefined): void; (middleware: SerializeMiddleware<...>, options: SerializeHandlerOptions & AbsoluteLocation): void; (middleware: BuildMiddleware<...>, options: BuildHandlerOptions & ...' is not assignable to type '{ (middleware: InitializeMiddleware<any, MetadataBearer>, options?: (InitializeHandlerOptions & AbsoluteLocation) | undefined): void; (middleware: SerializeMiddleware<...>, options: SerializeHandlerOptions & AbsoluteLocation): void; (middleware: BuildMiddleware<...>, options: BuildHandlerOptions & AbsoluteLocation):...'. npm error Types of parameters 'middleware' and 'middleware' are incompatible. npm error Types of parameters 'context' and 'context' are incompatible. npm error Type 'import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@aws-sdk/middleware-host-header/node_modules/@smithy/types/dist-types/middleware").HandlerExecutionContext' is not assignable to type 'import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@smithy/types/dist-types/middleware").HandlerExecutionContext'. npm error Types of property '[SMITHY_CONTEXT_KEY]' are incompatible. npm error Type '{ [key: string]: unknown; service?: string | undefined; operation?: string | undefined; commandInstance?: import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@aws-sdk/middleware-host-header/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any> | undefined; selectedHttpAuthScheme?:...' is not assignable to type '{ [key: string]: unknown; service?: string | undefined; operation?: string | undefined; commandInstance?: import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any> | undefined; selectedHttpAuthScheme?: import("/Users/ruojiazh/proj/aws-toolkit-vsc...'. npm error Type '{ [key: string]: unknown; service?: string | undefined; operation?: string | undefined; commandInstance?: import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@aws-sdk/middleware-host-header/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any> | undefined; selectedHttpAuthScheme?:...' is not assignable to type '{ [key: string]: unknown; service?: string | undefined; operation?: string | undefined; commandInstance?: import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any> | undefined; selectedHttpAuthScheme?: import("/Users/ruojiazh/proj/aws-toolkit-vsc...'. npm error Types of property 'commandInstance' are incompatible. npm error Type 'import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@aws-sdk/middleware-host-header/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any> | undefined' is not assignable to type 'import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any> | undefined'. npm error Type 'import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@aws-sdk/middleware-host-header/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any>' is not assignable to type 'import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@smithy/types/dist-types/command").Command<any, any, any, any, any>'. npm error The types of 'middlewareStack.add' are incompatible between these types. npm error Type '{ (middleware: import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@aws-sdk/middleware-host-header/node_modules/@smithy/types/dist-types/middleware").InitializeMiddleware<any, any>, options?: (import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@aws-sdk/middleware-host-header/node_modules/@smithy/t...' is not assignable to type '{ (middleware: import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@smithy/types/dist-types/middleware").InitializeMiddleware<any, any>, options?: (import("/Users/ruojiazh/proj/aws-toolkit-vscode/node_modules/@smithy/types/dist-types/middleware").InitializeHandlerOptions & import("/Users/ruojiazh/proj/aws-t...'. npm error Types of parameters 'options' and 'options' are incompatible. npm error Type 'SerializeHandlerOptions & AbsoluteLocation' is not assignable to type '(InitializeHandlerOptions & AbsoluteLocation) | undefined'. npm error Type 'SerializeHandlerOptions & AbsoluteLocation' is not assignable to type 'InitializeHandlerOptions & AbsoluteLocation'. npm error Type 'SerializeHandlerOptions & AbsoluteLocation' is not assignable to type 'InitializeHandlerOptions'. npm error Types of property 'step' are incompatible. npm error Type '"serialize"' is not assignable to type '"initialize"'. ``` ## Reason for Compatibility Error Upgrading @aws-sdk/client-lambda to version 3.953.0+ (which uses Smithy v4) causes TypeScript compilation errors due to module path conflicts. The toolkit's awsClientBuilderV3 uses Smithy v3 types, while the new Lambda client uses Smithy v4 types. Even though the types are structurally identical, TypeScript treats them as incompatible because they're imported from different module paths. ## Solution Added type assertions (as any and as LambdaSdkClient) in lambdaClient.ts to bypass TypeScript's type checking when creating the Lambda client. This allows the new SDK version to work while maintaining runtime compatibility. No new tests are required for the lambdaClient.ts changes because there is no behavior change - The type assertions don't change runtime behavior, only bypass compile-time type checking. The Lambda client functions identically before and after. --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license. Co-authored-by: Chengjun Li <>
…8537) ## Problem - Users without pre-configured credentials encounter authentication errors when opening Lambda functions from console - Credential mismatches between console account and local profile cause errors even when function is accessible in console: - `ResourceNotFoundException` when function exists in console account but not in local profile account - `AccessDeniedException` when local credentials lack `lambda:GetFunction` permission but console credentials have access ## Solution - Add `setupConsoleConnection()` to encapsulate browser-based AWS CLI `aws login` authentication and use the new connection - Add `getFunctionWithFallback()` to retrieve Lambda configuration with automatic console login fallback - Integrate fallback into `openLambdaFolderForEdit()` to handle missing credentials and credential mismatches - Improve error handling to distinguish credential mismatches and resource access issues - Handle `ResourceNotFoundException` by showing account-specific error message before fallback - Handle `AccessDeniedException` by showing permission error message before fallback ### Screenshots #### Show warning message when Lambda GetFunction API returns ResourceNotFoundException, then automatically proceed with console login flow <img width="461" height="90" alt="Screenshot 2026-01-29 at 12 29 00 AM" src="https://github.com/user-attachments/assets/1c1c700f-5585-4684-bcae-9daa43add315" /> #### Show warning message when Lambda GetFunction API returns AccessDeniedException, then automatically proceed with console login flow <img width="463" height="91" alt="Screenshot 2026-01-29 at 12 28 07 AM" src="https://github.com/user-attachments/assets/dce48127-1cca-406e-b966-ebc615ef5fa6" /> ## Background The Lambda `load-function` URI handler enables a seamless workflow where users can click "Open in Visual Studio Code" from the AWS Lambda console to view, edit, and deploy their Lambda functions directly in their preferred IDE. This feature downloads the function code locally, opens it in VS Code, and allows users to make changes and deploy updates back to AWS—all without leaving their development environment. ## Testing - [X] Tested with no local credentials configured - [X] Tested credential mismatch scenarios: - ResourceNotFoundException (function in console account but not local profile account) - AccessDeniedException (local credentials lack permission, console credentials have access) - [X] Tested user cancellation flow - [X] Test with SSO connection active --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license.
## Problem - `Amazon Q: Fix all Errors` feature does not work on warning issues. ## Solution - If user click on `Amazon Q: Fix all Issue` feature from warning issue, Q should fix both errors and warnings. - If user click on `Amazon Q: Fix all Issue` feature from error issue, Q should fix only errors. --- - Treat all work as PUBLIC. Private `feature/x` branches will not be squash-merged at release time. - Your code changes must meet the guidelines in [CONTRIBUTING.md](https://github.com/aws/aws-toolkit-vscode/blob/master/CONTRIBUTING.md#guidelines). - License: I confirm that my contribution is made under the terms of the Apache 2.0 license.
This merges the released changes for rc-20260129 into main. MCM-143408862 --------- Co-authored-by: aws-toolkit-automation <>
…8520) Add support for multi-tenant Lambda functions by introducing a Tenant ID input field in the Local Invoke configuration panel. The field appears conditionally when the SAM template contains TenancyConfig (either at function-level or in Globals section). The tenant ID value is saved in launch.json and passed to SAM CLI when invoking Lambda functions locally. <img width="619" height="862" alt="Screenshot 2026-01-29 at 10 16 29 AM" src="https://github.com/user-attachments/assets/985e01ce-cbcd-4204-a1ce-37ea9c1fca70" /> --------- Co-authored-by: Chengjun Li <>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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.
Automatic merge failed
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):