fix(lambda): add console credential fallback for Lambda URI handler by keenwilson · Pull Request #8537 · aws/aws-toolkit-vscode

keenwilson · 2026-01-27T23:11:41Z

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

Show warning message when Lambda GetFunction API returns AccessDeniedException, then automatically proceed with console login flow

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

Tested with no local credentials configured
Tested credential mismatch scenarios:
- ResourceNotFoundException (function in console account but not local profile account)
- AccessDeniedException (local credentials lack permission, console credentials have access)
Tested user cancellation flow
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.
License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

amazon-inspector-ohio · 2026-01-27T23:11:45Z

⏳ I'm reviewing this pull request for security vulnerabilities and code quality issues. I'll provide an update when I'm done

amazon-inspector-ohio · 2026-01-27T23:12:16Z

✅ I finished the code review, and didn't find any security or code quality issues.

valerena · 2026-01-29T00:08:20Z

packages/core/src/auth/utils.ts

+export async function getIAMConnectionOrFallbackToConsole(name: string, region: string): Promise<Connection> {
+    const tryActiveConnection = await getIAMConnection({ prompt: false })
+
+    if (tryActiveConnection && isIamConnection(tryActiveConnection)) {


Why do we need to check that it's an IamConnection?

The previous getFunctionWithCredentials used a fromSSO for the case where the connection wasn't iam.

aws-toolkit-vscode/packages/core/src/shared/clients/lambdaClient.ts

Lines 350 to 351 in 8b4d088

const credentials =

connection.type === 'iam' ? await connection.getCredentials() : fromSSO({ profile: connection.id })

should we still consider that case too before going to create a console connection?

Good call. I removed the IamConnection type pre-check.

valerena · 2026-01-29T00:11:54Z

packages/core/src/lambda/commands/editLambda.ts

+    const connection = await getIAMConnectionOrFallbackToConsole(name, region)
+
+    try {
+        return await getFunctionWithCredentials(region, name)


We retrieved the credentials in this getIAMConnectionOrFallbackToConsole, but then we're not using those credentials here, so inside this method we need to get the credentials again. Shouldn't we pass the credentials directly here, now that we have them? Or is there a reason to just make the method retrieve them directly instead of passing them as a parameter?

Thank you for pointing this out. I removed getIAMConnectionOrFallbackToConsole entirely since it duplicated credential retrieval logic in getFunctionWithCredentials.

valerena · 2026-01-29T00:19:33Z

packages/core/src/lambda/commands/editLambda.ts

+            getLogger().warn(message)
+        }
+        // Retry once with console credentials after credential mismatch. If second attempt fails, throw the error up.
+        await createAndUseConsoleConnection(name, region)


Just to confirm the behavior:
So we're trying to get the credentials. If there are credentials we use those, but if they don't exist, we create the console connection.
Then we try to get the function, but if we fail because of different reasons, then we try again to create the console connection.

Could it happen that we create the console connection twice? If they didn't have a connection initially so we create the console connection, but then their console session has one of these errors? (maybe we want to retry?)

This was a very good point. I cleaned up the retry behavior to avoid setting up console connection for the second-time.

Here are the current scenarios handled by getFunctionWithFallback:

Active connection → success (no console setup) Active connection → get function error (ResourceNotFoundException/AccessDeniedException) → show message → console retry → success Active connection → get function error (other errors) → console retry (no message) → success No connection → console setup → success No connection → console setup → get function error (ResourceNotFoundException/AccessDeniedException) → show message → throw (no retry) No connection → console setup → get function error (other errors) → throw (no message, no retry) No connection → console setup error → throw (no message)

seshubaws · 2026-01-29T00:29:50Z

packages/core/src/auth/utils.ts

+ * @returns Connection created from console credentials
+ * @throws ToolkitError if connection creation fails
+ */
+export async function createAndUseConsoleConnection(profileName: string, region: string): Promise<Connection> {


small thing but i wonder since this method says it's doing two things by way of the "and" should it be split into two methods for maintainability?

Agreed. I refactored the credential ID handling and made this function (renamed to setupConsoleConnection) only owns the console-connection setup path. The extra getConnection check was removed since useConnection already validates internally.

seshubaws · 2026-01-29T00:44:13Z

packages/core/src/auth/utils.ts

+            await tryActiveConnection.getCredentials()
+            return tryActiveConnection
+        } catch (error) {
+            // Fall back to console credentials for any credential retrieval error


Should we log something here?

Since we removed the redundant credential pre-check, this log is no longer needed.

seshubaws · 2026-01-29T00:45:17Z

packages/core/src/auth/utils.ts

+ * @throws ToolkitError if console login fails
+ */
+export async function getIAMConnectionOrFallbackToConsole(name: string, region: string): Promise<Connection> {
+    const tryActiveConnection = await getIAMConnection({ prompt: false })


nit: lets just name this activeConnection, feels redundant to have "tryActiveConnection" inside the try block

Really appreciate the detailed feedback. I updated to activeConnection. Thanks a lot, Seshu.

…nctionWithFallback`

…r fails (#8580) ## Problem - #8537 introduced setupConsoleConnection() and getFunctionWithFallback() to handle authentication fallback for Lambda console-to-IDE transitions. - When developers click "Open in VSCode" and their local AWS profile is invalid, toolkit automatically triggers browser-based console login as a fallback. However, console login requires prerequisites that not all developers can complete. When developers cancel console login, the CLI never writes the connection profile to disk. The Toolkit then attempts to use this non-existent connection, resulting in "Connection does not exist" errors. <img width="471" height="265" alt="problem-before-the-fix-connection-does-not-exist" src="https://github.com/user-attachments/assets/fd973ce1-7b28-4474-8b55-b0408c67e0ce" /> ## Solution - Verify connection exists in `setupConsoleConnection()` after "aws.toolkit.auth.consoleLogin" completes - Show warning message with link to [prerequisites documentation](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sign-in.html#cli-configure-sign-in-prerequisites) when connection verification fails - Throw ToolkitError to halt execution and prevent downstream connection usage <img width="1293" height="302" alt="update-message-with-learnmore" src="https://github.com/user-attachments/assets/a1d35f14-4c42-43c1-8417-b6532ed00e9a" /> <img width="1042" height="625" alt="click-learnmore-show-dialog" src="https://github.com/user-attachments/assets/aace3330-4ea8-4bd8-ad24-e8e956f09c45" /> ### 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. --- - 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.

keenwilson requested a review from a team as a code owner January 27, 2026 23:11

keenwilson force-pushed the feature/console-to-ide-credentials branch 2 times, most recently from 3aca6d4 to 7e51e8f Compare January 27, 2026 23:31

fix(lambda): add console credential fallback for Lambda URI handler

ea1adf8

keenwilson force-pushed the feature/console-to-ide-credentials branch from 7e51e8f to ea1adf8 Compare January 27, 2026 23:52

keenwilson added 4 commits January 27, 2026 15:53

Merge branch 'master' into feature/console-to-ide-credentials

57e7da7

test: stub Auth.instance.activeConnection to fix tests in CI

2cb8aec

chore: trigger CI

5799e83

chore: trigger CI

ff3ff7d

valerena reviewed Jan 29, 2026

View reviewed changes

seshubaws reviewed Jan 29, 2026

View reviewed changes

keenwilson added 8 commits January 28, 2026 18:49

fix(lambda): inline console creds fallback logic directly into `getFu…

bdd1c57

…nctionWithFallback`

refactor: setupConsoleConnection and improve retry logic

741ce96

simplify message

156f63d

Merge branch 'master' into feature/console-to-ide-credentials

48ca18c

chore: trigger CI

7542551

chore: trigger CI

edf8e30

chore: trigger CI

2d1de8d

chore: trigger CI

d93d3aa

valerena approved these changes Jan 29, 2026

View reviewed changes

chungjac approved these changes Jan 29, 2026

View reviewed changes

Will-ShaoHua approved these changes Jan 29, 2026

View reviewed changes

ashishrp-aws merged commit 8dccd29 into aws:master Jan 29, 2026
34 checks passed

keenwilson mentioned this pull request Feb 16, 2026

fix(auth): prevent connection usage when console login is cancelled or fails #8580

Merged

	const credentials =
	connection.type === 'iam' ? await connection.getCredentials() : fromSSO({ profile: connection.id })

Conversation

keenwilson commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Screenshots

Show warning message when Lambda GetFunction API returns ResourceNotFoundException, then automatically proceed with console login flow

Show warning message when Lambda GetFunction API returns AccessDeniedException, then automatically proceed with console login flow

Background

Testing

Uh oh!

amazon-inspector-ohio bot commented Jan 27, 2026

Uh oh!

amazon-inspector-ohio bot commented Jan 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

keenwilson commented Jan 27, 2026 •

edited

Loading