Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS Bedrock provider doesn't work unless using bedrockOptions #3018

Open
elie222 opened this issue Sep 16, 2024 · 3 comments · May be fixed by #3130
Open

AWS Bedrock provider doesn't work unless using bedrockOptions #3018

elie222 opened this issue Sep 16, 2024 · 3 comments · May be fixed by #3130
Labels
ai/provider bug Something isn't working

Comments

@elie222
Copy link

elie222 commented Sep 16, 2024

Description

This works:

createAmazonBedrock({
          bedrockOptions: {
            region: env.BEDROCK_REGION,
            credentials: {
              accessKeyId: env.BEDROCK_ACCESS_KEY,
              secretAccessKey: env.BEDROCK_SECRET_KEY,
            },
          },
        })(model)

This works when running locally, but not when deploying to Vercel:

createAmazonBedrock({
            region: env.BEDROCK_REGION,
              accessKeyId: env.BEDROCK_ACCESS_KEY,
              secretAccessKey: env.BEDROCK_SECRET_KEY,
          },
        })(model)

I imagine the issue is that Vercel is setting a key that causes the error (https://vercel.com/docs/projects/environment-variables/reserved-environment-variables#allowed-environment-variables). But I didn't manage to track down the error. bedrockOptions worked for me though.

Code example

No response

Additional context

No response

@lgrammel lgrammel added bug Something isn't working ai/provider labels Sep 16, 2024
@shaper
Copy link
Contributor

shaper commented Sep 22, 2024

Notes while investigating though I don't have a proposed fix yet:

I can reproduce the issue. As you suggest, it looks like an AWS_SESSION_TOKEN env var is set in the deployment but not when running locally. This is used by AI SDK logic as the default value for sessionToken when instantiating the AWS BedrockRuntimeClient.

Both of your examples (with the noted typo below fixed) work for me locally. In a deployment, the second one seems to execute one query successfully but subsequent queries fail, perhaps due to re-use of a session token intended for refresh (though passing the session token along at all is unintended AFAIK and so part of the bug).

I'm not sure what's setting the env var: Vercel's containing environment, the AWS lib, or something else. A clean app without anything AWS installed exhibits the env var set when a serverless function executes, so I think it's the Vercel environment.

Side note -- there is an extra closing curly brace in your doesn't-work example above. It looks like a typo from removing the credentials sub-object. Here is the corrected second example:

createAmazonBedrock({
  region: env.BEDROCK_REGION,
  accessKeyId: env.BEDROCK_ACCESS_KEY,
  secretAccessKey: env.BEDROCK_SECRET_KEY,
})(model)

@shaper
Copy link
Contributor

shaper commented Sep 23, 2024

For an AI SDK fix, I am wondering whether perhaps we should remove the fallback to AWS_XXX vars in this provider, since as it is we risk clashing with values set by an external runtime that differ from what the user intends. The basic problem is that one typically has some creds one wants to use for interacting with Bedrock (say creds set A), but here we're running in a serverless function that has a bunch of env vars already set (say creds set B) and we can unintentionally partially merge the two.

It's only the token that's problematic currently, but if we special-case it (don't use its value as a fallback since it can be set outside of the user's control) but leave the others, then we have an API that could surprise a developer.

We could prefix the default env var names with AI_SDK_ to avoid conflict, but this would be the first provider where we'd be doing that.

@elie222
Copy link
Author

elie222 commented Sep 23, 2024

For an AI SDK fix, I am wondering whether perhaps we should remove the fallback to AWS_XXX vars in this provider, since as it is we risk clashing with values set by an external runtime that differ from what the user intends. The basic problem is that one typically has some creds one wants to use for interacting with Bedrock (say creds set A), but here we're running in a serverless function that has a bunch of env vars already set (say creds set B) and we can unintentionally partially merge the two.

It's only the token that's problematic currently, but if we special-case it (don't use its value as a fallback since it can be set outside of the user's control) but leave the others, then we have an API that could surprise a developer.

We could prefix the default env var names with AI_SDK_ to avoid conflict, but this would be the first provider where we'd be doing that.

Yes, I agree it should be renamed as it's already in use by Vercel for other purposes. And many people using this library will encounter that issue.

shaper added a commit to shaper/ai that referenced this issue Sep 27, 2024
Deployments using the Bedrock provider can run in a serverless
function that pre-declares a value for `AWS_SESSION_TOKEN`
representing an alternate set of credentials than those intended and
specified by the developer. If we silently use the environment
variable for a default it can create a non-obvious credentials failure
that surprises the developer.

The session token credentials are less commonly used, and the
developer can still pass them along manually (and reference the
environment variable themselves if they choose to do so).

We also update the documentation to state this behavior as it's
admittedly deviant from common practice in the AI SDK providers (but
for good reason due to the idiosyncratic way it can be already-present
in the serverless environment).

Fixes vercel#3018.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ai/provider bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants