Skip to content

fix(budgateway): enable graceful degradation for unsupported guardrail providers #756

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(budgateway): enable graceful degradation for unsupported guardrail providers #756

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 7 additions & 8 deletions services/budgateway/tensorzero-internal/src/guardrail_table.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -163,14 +163,13 @@ impl GuardrailConfig {

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
Comment on lines 164 to +172
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot Nov 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Unsupported providers still trigger fail-fast errors

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 👍 / 👎.

}
Comment on lines 165 to 173
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Nov 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

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.


// Validate that enabled probes are not empty
Expand Down
Loading