feat: add BedrockMantleKeyConfig support to key hashing, schema/table mapping, and sensitive field clearing

[Pratham-Mishra04]

Summary

Adds support for BedrockMantleKeyConfig across the key configuration pipeline, ensuring it is properly persisted, retrieved, and hashed alongside other provider key configs.

Changes

• BedrockMantleKeyConfig is now included when converting between schema keys and database table keys in schemaKeyFromTableKey, tableKeyFromSchemaKey, UpdateProvidersConfig, UpdateProvider, and AddProvider.
• BedrockMantleKeyConfig is now included in the key hash computation in GenerateKeyHash, so config changes to Bedrock Mantle keys are correctly detected.
• Bedrock Mantle sensitive fields (BedrockMantleAccessKey, BedrockMantleSecretKey, BedrockMantleSessionToken, BedrockMantleRegion, BedrockMantleRoleARN, BedrockMantleExternalID, BedrockMantleRoleSessionName, BedrockMantleKeyConfig) are cleared in the AfterFind hook on TableVirtualKeyProviderConfig, consistent with how existing Bedrock sensitive fields are handled.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

Configure a provider key with BedrockMantleKeyConfig set and verify:

1. The key is correctly persisted to and retrieved from the database with the Mantle config intact.
2. Modifying BedrockMantleKeyConfig results in a different config hash, triggering a config reload.
3. Sensitive Bedrock Mantle fields are not exposed when fetching virtual key provider configs.

go test ./framework/configstore/...

Breaking changes

• Yes
• No

Security considerations

Sensitive Bedrock Mantle credential fields are cleared in the AfterFind hook, preventing them from being inadvertently exposed through virtual key provider config reads. This follows the same pattern already in place for standard Bedrock credentials.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Pratham-Mishra04]

• feat: add BedrockMantleKeyConfig support to key hashing, schema/table mapping, and sensitive field clearing #4886 👈 (View in Graphite)
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 57 seconds

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 29201447-7b65-49fd-bfc2-9759df7302a8

📥 Commits

Reviewing files that changed from the base of the PR and between 556cdac and 9bb15e0.

📒 Files selected for processing (4)

• framework/configstore/clientconfig.go
• framework/configstore/rdb.go
• framework/configstore/tables/virtualkey.go
• transports/bifrost-http/lib/config_test.go

📝 Walkthrough

Walkthrough

This change extends handling of BedrockMantleKeyConfig throughout the configstore: it is now included in key hash generation, mapped between DB and API key schemas, persisted in provider write paths (update/add), and cleared as a sensitive field after DB reads.

Changes

Bedrock Mantle key config support

Layer / File(s)	Summary
Key hash generation framework/configstore/clientconfig.go	GenerateKeyHash now marshals and hashes BedrockMantleKeyConfig when present, returning an error on marshal failure.
Schema mapping and provider write paths framework/configstore/rdb.go	schemaKeyFromTableKey/tableKeyFromSchemaKey map BedrockMantleKeyConfig between DB and API representations; UpdateProvidersConfig, UpdateProvider, and AddProvider persist this field in tables.TableKey rows.
Sensitive field redaction framework/configstore/tables/virtualkey.go	AfterFind clears Bedrock Mantle sensitive fields (access/secret/session keys, region, role ARN, external ID, role session name, key config) on associated keys.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: danpiths

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding BedrockMantleKeyConfig support across hashing, schema mapping, and sensitive-field clearing.
Description check	✅ Passed	The description matches the template well, covering summary, changes, type, affected areas, testing, breaking changes, security, and checklist.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 07-03-fix_bedrock_mantle_key_saving_fixes

---

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 5/5

Safe to merge — changes are additive field additions that follow the exact same pattern as Azure, Vertex, and Bedrock configs throughout the pipeline.

All four touch points (schema↔table conversion, hash generation, AfterFind clearing, tests) are consistent with each other and with the existing provider config patterns. The BeforeSave hook in key.go already handles the flat-column serialization and encryption for Bedrock Mantle fields, so the omission of an explicit flat-column block in rdb.go (which exists for other providers) is harmless — BeforeSave overwrites those assignments anyway. Hash ordering places BedrockMantleKeyConfig between BedrockKeyConfig and Aliases, which preserves all existing hash values for keys without a Mantle config.

No files require special attention.

Important Files Changed

Filename	Overview
framework/configstore/rdb.go	Adds BedrockMantleKeyConfig to five struct literals across schemaKeyFromTableKey, tableKeyFromSchemaKey, UpdateProvidersConfig, UpdateProvider, and AddProvider; no explicit flat-column handling block added (unlike Azure/Vertex/Bedrock), but BeforeSave in key.go covers this correctly.
framework/configstore/clientconfig.go	Inserts a BedrockMantleKeyConfig hash block between BedrockKeyConfig and Aliases in GenerateKeyHash; nil-guarded so existing keys without Mantle config retain their hash.
framework/configstore/tables/virtualkey.go	Clears all seven Bedrock Mantle flat columns plus the virtual BedrockMantleKeyConfig field in AfterFind, consistent with the existing Azure, Vertex, and Bedrock clearing blocks.
transports/bifrost-http/lib/config_test.go	Adds two new hash test cases (key9, key9b) for BedrockMantleKeyConfig, verifying distinctness vs. no-Mantle and vs. a different region; follows the same structure as existing Bedrock test cases.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Caller
    participant rdb as rdb.go (UpdateProvider/etc)
    participant TableKey as tables/key.go (BeforeSave)
    participant GORM as GORM
    participant AfterFind as AfterFind hooks
    participant VKHook as virtualkey.go (AfterFind)

    Caller->>rdb: "schemas.Key{BedrockMantleKeyConfig: ...}"
    rdb->>TableKey: "TableKey{BedrockMantleKeyConfig: ...}"
    TableKey->>GORM: Save() triggers BeforeSave
    GORM->>TableKey: BeforeSave — copies fields to flat columns (BedrockMantleAccessKey, SecretKey, …), encrypts if enabled
    GORM-->>rdb: persisted

    Note over GORM,AfterFind: On subsequent reads (virtual key provider config)
    GORM->>AfterFind: TableKey.AfterFind — decrypts flat columns, reconstitutes BedrockMantleKeyConfig
    AfterFind->>VKHook: TableVirtualKeyProviderConfig.AfterFind
    VKHook->>VKHook: Clears all flat Mantle columns + BedrockMantleKeyConfig virtual field
    VKHook-->>Caller: sensitive fields omitted

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Caller
    participant rdb as rdb.go (UpdateProvider/etc)
    participant TableKey as tables/key.go (BeforeSave)
    participant GORM as GORM
    participant AfterFind as AfterFind hooks
    participant VKHook as virtualkey.go (AfterFind)

    Caller->>rdb: "schemas.Key{BedrockMantleKeyConfig: ...}"
    rdb->>TableKey: "TableKey{BedrockMantleKeyConfig: ...}"
    TableKey->>GORM: Save() triggers BeforeSave
    GORM->>TableKey: BeforeSave — copies fields to flat columns (BedrockMantleAccessKey, SecretKey, …), encrypts if enabled
    GORM-->>rdb: persisted

    Note over GORM,AfterFind: On subsequent reads (virtual key provider config)
    GORM->>AfterFind: TableKey.AfterFind — decrypts flat columns, reconstitutes BedrockMantleKeyConfig
    AfterFind->>VKHook: TableVirtualKeyProviderConfig.AfterFind
    VKHook->>VKHook: Clears all flat Mantle columns + BedrockMantleKeyConfig virtual field
    VKHook-->>Caller: sensitive fields omitted

Loading

_{Reviews (2): Last reviewed commit: "fix: bedrock mantle key saving fixes" | Re-trigger Greptile}

[Pratham-Mishra04]

Merge activity

• Jul 3, 1:40 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jul 3, 1:40 PM UTC: @Pratham-Mishra04 merged this pull request with Graphite.