fix(media-understanding): use aws-sdk credentials for bedrock image models#97525
fix(media-understanding): use aws-sdk credentials for bedrock image models#97525CrypticDriver wants to merge 1 commit into
Conversation
…odels The image-understanding path called requireApiKey() unconditionally in prepareResolvedImageRuntime(). For amazon-bedrock providers using auth: "aws-sdk", the resolved API key is legitimately empty because credentials come from the AWS SDK chain (env vars / shared ~/.aws files / EC2 instance-role IMDS / ECS container role). The bedrock-converse stream signs requests with those SDK credentials and never consumes an API key, and the main chat path never calls requireApiKey for aws-sdk. Requiring a key here made image analysis fail with "No API key resolved for provider ... (auth mode: aws-sdk ...)" on every bedrock deployment without a static key in env, while chat worked. Now aws-sdk mode keeps an empty key and defers to the SDK chain; all other auth modes still require a usable key. Adds a regression test.
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. The image fix is useful, but #72092 is the stronger open landing path: it is mergeable, proof-positive, linked to the canonical issue, and covers the same image failure plus sibling audio/video media auth paths. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: #72031 reports the same Bedrock So I’m closing this here and keeping the remaining discussion on #72092 and #72031. Review detailsBest possible solution: Close this PR in favor of reviewing and landing #72092, which is the broader proof-positive fix for the canonical Bedrock media aws-sdk auth issue. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection and the canonical issue show that Bedrock Is this the best way to solve the issue? No. This PR is a plausible image-only fix, but #72092 is the better landing path because it covers the same image failure, includes stronger live proof, and handles sibling audio/video media paths for the same auth class. Security review: Security review cleared: No supply-chain, workflow, dependency, secret-handling, or new code-execution surface is added by this two-file runtime/test diff. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 27c1685f106d. |
|
ClawSweeper applied the proposed close for this PR.
|
What Problem This Solves
When
agents.defaults.imageModelpoints at anamazon-bedrockmodel and the provider usesauth: "aws-sdk", the image-understanding tool fails with:…even though the same bedrock model works fine for normal chat.
aws-sdkauth resolves credentials lazily through the AWS SDK credential chain (env vars, shared~/.awsfiles, EC2 instance-role IMDS, ECS container role), so the resolved API key is legitimately empty. The bedrock-converse provider stream signs requests with those SDK credentials and never consumes an API key, and the main chat path never callsrequireApiKeyforaws-sdk.The image path in
src/media-understanding/image.ts(prepareResolvedImageRuntime) unconditionally calledrequireApiKey(...), which throwsMissingProviderAuthErrorwhenever the key is empty. This wrongly blocked image analysis for every bedrock deployment that relies on instance-role / default-profile / SSO credentials (no static key in env) — chat worked, the image tool did not.Evidence
Repro before the fix (EC2 host, bedrock credentials via instance role; chat works, image tool fails):
imageModel = amazon-bedrock/global.anthropic.claude-opus-4-8, providerauth: "aws-sdk".All image models failed (2): amazon-bedrock/global.anthropic.claude-opus-4-8: No API key resolved for provider "amazon-bedrock" (auth mode: aws-sdk, checked: aws-sdk default chain). | amazon-bedrock/global.anthropic.claude-opus-4-7: No API key resolved ...Fix (
src/media-understanding/image.ts) — branch on auth mode soaws-sdkkeeps an empty key and defers to the SDK chain, while all other modes still require a usable key:Regression test added in
src/media-understanding/image.test.ts— "lets amazon-bedrock image models use aws-sdk credentials without an API key" — asserts that for anaws-sdkbedrock model the path (1) never callsrequireApiKey, (2) stores an empty runtime key (setRuntimeApiKey("amazon-bedrock", "")), and (3) reaches the provider completion withapiKey: "".Local test run (added test + existing suite, on the EC2 host above):