Merge master into feature/qOnly #8524
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
…edentials (#8500) ## Problem AWS CLI update process enters an infinite retry loop when outdated CLI is detected (exit code 252), causing continuous failed authentication attempts and poor user experience. ## Solution #### CLI update loop - affects users with outdated CLI - Remove automatic retry loop for AWS CLI updates to prevent infinite recursion - Show warning message when CLI update is attempted, requiring retry - Remove try-catch wrapper: it was swallowing errors and allowing profile activation to proceed despite failed CLI execution, causing invalid credential state <img width="1196" height="798" alt="1-need-update" src="https://github.com/user-attachments/assets/94a038bd-4972-4202-a940-e7b16348f465" /> <img width="1198" height="798" alt="2-run-installer" src="https://github.com/user-attachments/assets/343d8ad9-2fe2-4581-bbd9-68b063340441" /> <img width="1196" height="798" alt="3-install-successful" src="https://github.com/user-attachments/assets/5bfdf0af-44bf-4559-8a84-672f25851827" /> <img width="476" height="149" alt="4-warning-to-retry" src="https://github.com/user-attachments/assets/22d1e5dd-bd29-400a-b8ce-504e5acf1cf6" /> #### Testing: - Tested AWS CLI update scenario (exit code 252) with single update attempt and manual retry - Confirmed no infinite loops during installation --- - 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 <[email protected]>
# Summary This PR migrates the SQLWorkbench custom API client from the deprecated AWS SDK v2 generator pattern to standalone AWS SDK v3-compatible packages. This migration is required as part of the broader AWS Toolkit repository migration from SDK v2 to v3. # Problem The AWS Toolkit VSCode repository is deprecating the centralized generateServiceClient.ts script that generates TypeScript clients from service JSON definitions. The SageMaker Unified Studio (SMUS) team currently uses this v2 generator for SQLWorkbench. # Solution * Created standalone package @amzn/sql-workbench-client * Updated imports to use new standalone package * Migrated from SDK v2 .promise() pattern to SDK v3 Command pattern (client.send(command)) * Updated credential handling to use credential provider function for auto-refresh support * Replaced local type definitions with SDK-provided types (DatabaseConnectionConfiguration, ParentResource, Resource, etc.) * Removed dependency for SQLWorkbench on the deprecated generateServiceClient.ts script * Updated unit tests to mock SDK v3 send method instead of v2 .promise() pattern --- - 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]>
…8490) ## Description This PR fixes a bug where space status was incorrectly displayed for spaces with mixed-case names. ## Problem The SageMaker ListApps API's SpaceNameEquals filter is case-sensitive, but space names in SMUS (SageMaker Unified Studio) can have mixed case. When a space name contained uppercase characters, the API would not find the matching app, causing incorrect status display in the UI. ## Solution Added listAppsForDomainMatchSpaceIgnoreCase method with an optimization: If the space name is all lowercase, uses the efficient listAppForSpace method with SpaceNameEquals filter (server-side filtering) Otherwise, fetches all apps via listAppsForDomain and performs case-insensitive client-side matching ## Changes * packages/core/src/shared/clients/sagemaker.ts: Added listAppsForDomainMatchSpaceIgnoreCase method * packages/core/src/awsService/sagemaker/sagemakerSpace.ts: Updated updateSpaceAppStatus() to use the new method ## Technical Notes: Why Batch Polling Optimization Was Not Implemented Goal: Since listAppsForDomainMatchSpaceIgnoreCase fetches all apps in a domain (for case-insensitive matching), ideally we could reuse this single API response to update multiple spaces in the same domain simultaneously, reducing redundant API calls during polling. Why It's Difficult: Per-Space Update Architecture: The current updateSpaceAppStatus() method is designed to update a single space. It's called individually for each space by the PollingSet timer. Shared Method for Different Use Cases: The same updateSpaceAppStatus() method serves two purposes: Initial status refresh: Triggered by user action (e.g., clicking "Connect"). Requires real-time data to correctly determine if the space should be added to the polling set. Periodic polling updates: Triggered by PollingSet timer. Could potentially use shared/batched data. Real-time Data Requirement: When a user triggers an action, the initial refresh must return real-time data. If the status is stale, the space might not be added to the polling set, causing the UI to not update properly after user actions. Refactoring Scope: To properly implement batch updates, we would need to separate the initial refresh logic from polling update logic, which is a significant architectural change beyond the scope of this bug fix. --- - 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]>
## Problem - When user connects to space, it creates a duplicate window for the same space ## Solution - Assign unique identifier to workspace. This will open same external window when connecting to same workspace. ## Notes - Test cases added in separate pr with unit tests - Retested locally for most recent changes 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.
# Summary This PR migrates the DataZone custom API client from the deprecated AWS SDK v2 generator pattern to standalone AWS SDK v3-compatible packages. This migration is required as part of the broader AWS Toolkit repository migration from SDK v2 to v3. The AWS Toolkit VSCode repository is deprecating the centralized generateServiceClient.ts script that generates TypeScript clients from service JSON definitions. The SageMaker Unified Studio (SMUS) team currently uses this v2 generator for DataZone Custom API. # Solution * Created standalone package @amzn/datazone-custom-client with SDK v3 patterns * Updated DataZoneCustomClientHelper to use SDK v3 client initialization and Command pattern * Migrated from client.methodName().promise() to client.send(new Command()) pattern * Updated credential provider to use SDK v3 async credential provider function * Updated imports to use new standalone package types and commands * Updated test files to mock SDK v3 send() method instead of v2 .promise() pattern * Removed dependency for DataZone Custom API on the deprecated generateServiceClient.ts script --- - 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: Laxman Reddy <[email protected]> Co-authored-by: invictus <[email protected]>
This merges the released changes for rc-20260115 into main. --- - 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 - 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
9 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):