fix(budgateway): enable graceful degradation for unsupported guardrail providers #756
Conversation
…l providers Convert hard error into warning when encountering unsupported provider types in guardrail configuration. This allows the system to continue operation by skipping unsupported providers instead of failing completely. Changes: - Replace error return with warning log for unsupported provider types - Add continue statement to skip validation for unsupported providers - Improve error message to indicate provider will be skipped during execution This enables better forward compatibility when new provider types are added externally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Summary of ChangesHello @dittops, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request aims to make the guardrail configuration more resilient by allowing unsupported provider types without causing a hard failure. Instead of erroring out, it now logs a warning and skips validation for such providers. The change in guardrail_table.rs correctly handles this during configuration validation, preventing startup failures. However, I've pointed out a potential issue at runtime where an unsupported provider could still cause a failure if the guardrail is configured with FailFast failure mode. My review comment includes a suggestion to make the graceful degradation more robust by filtering out unsupported providers earlier in the execution flow.
| if !SUPPORTED_PROVIDERS.contains(&provider.provider_type.as_str()) { | ||
| return Err(crate::error::Error::new( | ||
| crate::error::ErrorDetails::Config { | ||
| message: format!( | ||
| "Unsupported provider type '{}' in guardrail '{}'", | ||
| provider.provider_type, self.id | ||
| ), | ||
| }, | ||
| )); | ||
| // Log warning instead of returning error for unknown providers | ||
| tracing::warn!( | ||
| "Unsupported provider type '{}' in guardrail '{}' - this provider will be skipped during execution", | ||
| provider.provider_type, | ||
| self.id | ||
| ); | ||
| continue; // Skip validation for unsupported providers | ||
| } |
There was a problem hiding this comment.
This change correctly prevents the application from failing at startup due to an unsupported guardrail provider by logging a warning instead of returning an error.
However, the graceful degradation at runtime appears incomplete. The execution logic in execute_single_probe (in guardrail.rs) will still attempt to process the unsupported provider, which results in an error. If the guardrail's failure_mode is set to FailFast, this will cause the entire guardrail execution to fail, which contradicts the goal of this PR. With BestEffort mode, it will result in redundant warning logs.
To fully implement graceful degradation, consider filtering out unsupported providers before they are executed, for example, within create_probe_tasks in guardrail.rs. This would ensure they are truly skipped during execution regardless of the failure_mode.
To implement this, you might need to move the SUPPORTED_PROVIDERS constant to the module level to make it accessible from guardrail.rs.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for provider in &self.providers { | ||
| if !SUPPORTED_PROVIDERS.contains(&provider.provider_type.as_str()) { | ||
| return Err(crate::error::Error::new( | ||
| crate::error::ErrorDetails::Config { | ||
| message: format!( | ||
| "Unsupported provider type '{}' in guardrail '{}'", | ||
| provider.provider_type, self.id | ||
| ), | ||
| }, | ||
| )); | ||
| // Log warning instead of returning error for unknown providers | ||
| tracing::warn!( | ||
| "Unsupported provider type '{}' in guardrail '{}' - this provider will be skipped during execution", | ||
| provider.provider_type, | ||
| self.id | ||
| ); | ||
| continue; // Skip validation for unsupported providers |
There was a problem hiding this comment.
The new validate implementation only logs and continues for unknown providers, but the providers remain in self.providers. Downstream code (create_probe_tasks → execute_single_probe) still builds probe tasks for every provider and returns ErrorDetails::Config { message: "Unsupported provider type" } when the type is not matched. With FailureMode::FailFast (the default when executing guardrails), any request that reaches execute_guardrail with an unsupported provider will still error at runtime rather than being skipped, so the intended “graceful degradation” never happens and failures merely move from startup to request handling.
Useful? React with 👍 / 👎.
Summary
Converts hard error into warning when encountering unsupported provider types
in guardrail configuration, enabling graceful degradation instead of complete
failure.
Changes
detected
continuestatementMotivation
This change improves forward compatibility and system resilience:
externally
Impact
provider type
with supported ones
Test Plan
guardrail config
🤖 Generated with Claude Code