feat: optimize Bedrock model configuration performance [close: #5419, #5420]

[KevinZhao]

1. Add ModelConfigCache class for model config caching strategy\n2. Remove deprecated legacy model definitions\n3. Optimize cross-region inference and custom ARN handling\n4. Add comprehensive test suite for cache functionality

Related GitHub Issue

Closes: #5419, #5420

Roo Code Task Context (Optional)

Description

Creating simple caching for model configuration to avoid multi invocation of getModel()
Remove some legacy models or embedding models.

Test Procedure

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

---

Important

Introduces caching for model configurations in AwsBedrockHandler, removes deprecated models, and adds tests for cache functionality.

• Caching:
  • Introduces ModelConfigCache class in bedrock.ts for caching model configurations.
  • AwsBedrockHandler uses ModelConfigCache to cache results of getModel().
  • Cache key generated based on ProviderSettings.
  • Cache invalidated when configuration changes.
• Model Definitions:
  • Removes deprecated model definitions from bedrockModels in bedrock.ts.
• Testing:
  • Adds bedrock-cache-strategy.spec.ts to test caching functionality.
  • Tests cover cache retrieval, cache key generation, cache invalidation, and performance benefits.
• Misc:
  • Optimizes cross-region inference and custom ARN handling in AwsBedrockHandler.

^{This description was created by for e81ff4d. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

Hey @KevinZhao I reviewed your PR and left a couple of suggestions.

Let me know if you have any questions!

[daniel-lxs]

I'm wondering about memory management for long-running applications. Since cache entries are never evicted, could this potentially lead to memory issues if many different model configurations are used over time? Would it make sense to implement a cache size limit or TTL (time-to-live) for entries?

[daniel-lxs]

Should we add error handling for the cache operations? While Map operations are generally safe, if we extend this cache in the future or if there are edge cases, having try-catch blocks could prevent unexpected failures from affecting the main flow.

[daniel-lxs]

Instead of using as any to access private properties, would it be cleaner to either make these properties protected for testing purposes or use a testing utility that provides type-safe access to private members? This would improve type safety in the tests.

[daniel-lxs]

Could we translate these Chinese comments to English for consistency? The comments explain that this simulates the model's inputPrice being updated to 8 after invokedModelId, which is a key part of the test verification.

[daniel-lxs]

The PR description mentions performance optimization, but I don't see any benchmarks or performance metrics. Would it be helpful to add performance tests that demonstrate the actual improvement? This would validate the optimization claims and help prevent performance regressions in the future.