Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: amazon-bedrock-mantle: IAM-generated bearer token not refreshed after discovery, expires causing silent auth failures [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#68900•Fetched 2026-04-19 15:06:28
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
wirjowirjo
Participants
wirjowirjo
Timeline (top)
cross-referenced ×1mentioned ×1referenced ×1subscribed ×1

The amazon-bedrock-mantle plugin generates a bearer token from IAM credentials at discovery time via @aws/bedrock-token-generator, then bakes it as a static string into the provider config (auth: "api-key", apiKey: <literal-token>).

After the token expires (~1-2 hours), subsequent requests fail silently because:

  1. resolveConfigApiKey only handles the explicit AWS_BEARER_TOKEN_BEDROCK env var — it returns undefined for IAM-generated tokens
  2. The in-memory iamTokenCache would return a fresh token, but nothing re-invokes generateBearerTokenFromIam after the initial discovery
  3. The cached token in the provider config is a frozen string that can't self-refresh

Root Cause

After the token expires (~1-2 hours), subsequent requests fail silently because:

Fix Action

Fixed

PR fix notes

PR #68903: fix(amazon-bedrock-mantle): refresh IAM bearer token via resolveConfigApiKey cache lookup

Description (problem / solution / changelog)

Problem

The amazon-bedrock-mantle plugin generates a bearer token from IAM credentials at discovery time via @aws/bedrock-token-generator, then bakes it as a static string into the provider config (auth: "api-key", apiKey: <literal-token>).

After the token's cache TTL expires (~1hr), requests fail silently because resolveConfigApiKey only handled the explicit AWS_BEARER_TOKEN_BEDROCK env var — returning undefined for IAM-generated tokens.

Fix

Expose getCachedIamToken(region) as a sync read from the existing iamTokenCache (no new async code), and wire it into resolveConfigApiKey as a fallback when no explicit env var is set.

The flow is now:

  1. catalog.run generates the IAM bearer token and caches it (existing behavior, unchanged)
  2. resolveConfigApiKey returns the cached token at auth resolution time (new behavior)
  3. When the cache expires, the next catalog.run refreshes it

Changes

FileChange
discovery.tsExport getCachedIamToken(region) — sync read from iamTokenCache
register.sync.runtime.tsUpdate resolveConfigApiKey to fall back to getCachedIamToken()
api.tsRe-export getCachedIamToken
discovery.test.ts3 new tests for getCachedIamToken (valid cache, empty cache, expired cache)

Testing

  • 3 new unit tests for getCachedIamToken
  • All existing tests unmodified

Fixes #68900

Changed files

  • extensions/amazon-bedrock-mantle/api.ts (modified, +1/-0)
  • extensions/amazon-bedrock-mantle/discovery.test.ts (modified, +28/-0)
  • extensions/amazon-bedrock-mantle/discovery.ts (modified, +15/-0)
  • extensions/amazon-bedrock-mantle/register.sync.runtime.ts (modified, +8/-2)
RAW_BUFFERClick to expand / collapse

Summary

The amazon-bedrock-mantle plugin generates a bearer token from IAM credentials at discovery time via @aws/bedrock-token-generator, then bakes it as a static string into the provider config (auth: "api-key", apiKey: <literal-token>).

After the token expires (~1-2 hours), subsequent requests fail silently because:

  1. resolveConfigApiKey only handles the explicit AWS_BEARER_TOKEN_BEDROCK env var — it returns undefined for IAM-generated tokens
  2. The in-memory iamTokenCache would return a fresh token, but nothing re-invokes generateBearerTokenFromIam after the initial discovery
  3. The cached token in the provider config is a frozen string that can't self-refresh

Reproduction

  1. Deploy OpenClaw on EC2/ECS with IAM role (no AWS_BEARER_TOKEN_BEDROCK env var)
  2. Configure amazon-bedrock-mantle as a provider
  3. Models work initially (token generated at discovery)
  4. Wait >1 hour — requests start failing with auth errors

Proposed Fix

Update resolveConfigApiKey to also serve the cached IAM token (sync path), and ensure the catalog re-runs periodically or the token cache TTL is extended to match the actual token lifetime (up to 12h).

Alternatively, add a per-request async auth hook to the plugin SDK that allows providers to refresh tokens dynamically.

Environment

  • OpenClaw: 2026.4.15+
  • Plugin: amazon-bedrock-mantle (added in #61296)
  • Auth: IAM role (instance profile / IRSA)
  • Region: us-east-1

Related

  • #62995 — similar "No API key found" regression for regular amazon-bedrock with aws-sdk auth
  • PR #62009 — fix for auth propagation to pi's authStorage
  • #61296 — original Mantle provider PR (by @wirjo)

extent analysis

TL;DR

Update the resolveConfigApiKey function to serve the cached IAM token and implement a mechanism to refresh the token periodically to prevent auth errors after token expiration.

Guidance

  • Investigate updating the resolveConfigApiKey function to handle IAM-generated tokens, allowing it to return the cached token when available.
  • Consider implementing a periodic refresh mechanism for the token cache to match the actual token lifetime (up to 12 hours) to prevent silent request failures.
  • Evaluate adding a per-request async auth hook to the plugin SDK for dynamic token refresh, as an alternative solution.
  • Review related issues (#62995, #62009, #61296) for potential insights into similar auth propagation and token management challenges.

Example

No code example is provided due to the complexity of the issue and the need for a more detailed understanding of the amazon-bedrock-mantle plugin and @aws/bedrock-token-generator library.

Notes

The proposed fix suggests updating the resolveConfigApiKey function and ensuring the catalog re-runs periodically or extending the token cache TTL. However, the implementation details and potential impact on the overall system require further investigation.

Recommendation

Apply a workaround by updating the resolveConfigApiKey function to serve the cached IAM token and implement a periodic token refresh mechanism, as this approach addresses the immediate issue and provides a foundation for further improvements.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#retrieval issue#search optimization#API routing#API middleware

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: amazon-bedrock-mantle: IAM-generated bearer token not refreshed after discovery, expires causing silent auth failures [1 pull requests, 1 participants]