feat: add timeout comments to guardrail rule and provider entries in `values.yaml` by BearTS · Pull Request #3612 · maximhq/bifrost

BearTS · 2026-05-20T08:45:42Z

Summary

Adds inline documentation comments to the Bifrost Helm chart values for timeout configuration fields, clarifying the units and defaults for rule and provider execution timeouts.

Changes

Updated the timeout comment for guardrail rules to specify seconds as the unit and note the default value of 60 seconds (previously showed 1000, which was ambiguous in terms of units)
Added a timeout comment for guardrail providers to document the default value of 30 seconds

Type of change

Affected areas

How to test

Deploy or lint the Helm chart to confirm the values file renders correctly.

helm lint helm-charts/bifrost

Breaking changes

Yes
No

Related issues

Security considerations

None.

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

coderabbitai · 2026-05-20T08:45:50Z

Warning

Rate limit exceeded

@BearTS has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 18 minutes and 16 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c0bd65cd-9045-47a0-9cdd-a2e03b4f7931

📥 Commits

Reviewing files that changed from the base of the PR and between f4a7c96 and 73494ef.

📒 Files selected for processing (2)

docs/enterprise/guardrails.mdx
helm-charts/bifrost/values.yaml

📝 Walkthrough

Walkthrough

The Bedrock content-filter guardrails policy timeouts are updated in the Helm values configuration. The rule execution timeout default is reduced from 1000 to 60 seconds, and a provider execution timeout of 30 seconds is added for the policy.

Changes

Bedrock Guardrails Timeout Configuration

Layer / File(s)	Summary
Bedrock guardrails timeout defaults `helm-charts/bifrost/values.yaml`	Rule execution timeout is reduced to 60 seconds and provider execution timeout is set to 30 seconds for the Bedrock content-filter guardrails policy.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

⏰✨ A rabbit hops through timeout lands,
Where Bedrock rules now have swift hands,
From a thousand down to sixty beats,
Faster filters, swifter feats,
Thirty seconds for the guard's last stand! 🛡️

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: adding timeout comments to guardrail configurations in the Helm values.yaml file.
Description check	✅ Passed	The description is complete and follows the template well, clearly explaining the documentation updates with proper sections and testing instructions.
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.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch 05-20-chore_add_timeout_example_in_providers_yaml_file

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

BearTS · 2026-05-20T08:45:55Z

chore: bump Bifrost Helm chart to 2.1.18 with feature flags, model catalog URL, and bug fixes #3623
feat: add configurable pod and container security contexts to postgresql deployment #3694
feat: support existingSecret for internal PostgreSQL auth in Bifrost Helm chart #3689
fix: sort provider secrets and weaviate env vars alphabetically for deterministic Helm rendering #3621
feat: add default password warnings for PostgreSQL and Redis in Helm chart NOTES.txt #3620
fix: gate Weaviate PVC creation on persistence.enabled #3619
fix: use REDISCLI_AUTH env var to avoid passing password via -a flag in Redis health checks #3618
feat: add optional gRPC port to bifrost cluster deployment and service #3617
feat: add timeout comments to guardrail rule and provider entries in values.yaml #3612 👈 (View in Graphite)
dev

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

greptile-apps · 2026-05-20T11:02:10Z

Confidence Score: 4/5

Safe to merge for the Helm chart changes; the docs file has a partial fix where description text was updated but example timeout values were not.

The values.yaml changes are correct and self-consistent. In docs/enterprise/guardrails.mdx, the unit change in the description text is right, but all the curl/API code examples still carry millisecond-scale timeout values (5000, 3000, 2000) that now contradict the "seconds" description — a user following those examples would configure timeouts of over an hour.

docs/enterprise/guardrails.mdx — the code example timeout values throughout the file need to be updated to match the now-documented seconds unit.

Important Files Changed

Filename	Overview
helm-charts/bifrost/values.yaml	Added inline timeout comments for guardrail rules (60s default) and providers (30s default); clean and consistent with the updated docs.
docs/enterprise/guardrails.mdx	Description text updated from "milliseconds" to "seconds (default: 60)", but code-example timeout values (5000, 3000, 2000) throughout the file were not updated and remain inconsistent with the new unit description.

_{Reviews (6): Last reviewed commit: "chore: add timeout example in providers ..." | Re-trigger Greptile}

## Summary Briefly explain the purpose of this PR and the problem it solves. ## Changes - What was changed and why - Any notable design decisions or trade-offs ## 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 Describe the steps to validate this change. Include commands and expected outcomes. ```sh # Core/Transports go version go test ./... # UI cd ui pnpm i || npm i pnpm test || npm test pnpm build || npm run build ``` If adding new configs or environment variables, document them here. ## Screenshots/Recordings If UI changes, add before/after screenshots or short clips. ## Breaking changes - [ ] Yes - [ ] No If yes, describe impact and migration instructions. ## Related issues Link related issues and discussions. Example: Closes #123 ## Security considerations Note any security implications (auth, secrets, PII, sandboxing, etc.). ## 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

## Summary Removes the hardcoded `type: "custom"` field that was being set by default for Anthropic tools during conversion. It is an optional field based on Anthropic docs and with this, can also support Deepseek as custom provider ## Changes - Removed the automatic assignment of `AnthropicToolTypeCustom` when initializing `AnthropicTool` in `convertBifrostToolToAnthropic`, allowing the tool type to be determined by subsequent logic rather than being overridden at construction time. ## Type of change - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [x] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test Send a request to the Anthropic provider with tools that are not of the custom type and verify they are correctly passed through without being overridden to `type: "custom"`. ```sh go test ./core/providers/anthropic/... ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. ## 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

## Summary When performing keyless `ListModels` requests, provider implementations were passing an empty `schemas.Key{}`, which caused model filtering to behave incorrectly — returning no models instead of all available models. This fix ensures keyless requests use a wildcard whitelist so all models are returned as expected. ## Changes - Replaced `schemas.Key{}` with `schemas.Key{Models: schemas.WhiteList{"*"}}` in the keyless `ListModels` path for Anthropic, Cohere, Gemini, HuggingFace, and OpenAI providers. - The wildcard `"*"` entry signals that all models should be allowed through the whitelist filter, matching the intended behavior for keyless configurations. ## Type of change - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [x] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test Call `ListModels` against a provider configured with `IsKeyLess: true` and verify that the response includes the full list of available models rather than an empty result. ```sh go test ./... ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues - Resolves #3607 ## Security considerations No security implications. The wildcard whitelist only affects model listing behavior in explicitly keyless provider configurations. ## Checklist - [x] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [x] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable

…ms (#3647) ## Summary When navigating between sidebar pages that support time filtering, the selected time range (start/end time or period) is lost. This PR preserves the active time filter parameters when clicking sidebar sub-items, so users don't have to re-select their time range after switching between time-filter-enabled pages. ## Changes - When navigating from one `TimeFilterPages` page to another via a sidebar sub-item, the current `start_time`, `end_time`, and `period` query parameters are carried over to the destination URL. - If the current or destination page is not in `TimeFilterPages`, navigation behaves as before with no parameter forwarding. ## Type of change - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [x] UI (React) - [ ] Docs ## How to test 1. Navigate to a page that supports time filtering (e.g., a metrics or logs page). 2. Set a custom time range or period using the time filter. 3. Click a different sidebar sub-item that also supports time filtering. 4. Verify the time range is preserved in the URL and the view reflects the same time window. 5. Navigate to a sidebar sub-item that does **not** support time filtering and verify no time parameters are appended. ```sh cd ui pnpm i || npm i pnpm test || npm test pnpm build || npm run build ``` ## Screenshots/Recordings N/A ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations No security implications. Only query parameters already present in the current URL are forwarded. ## 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

…edirect (#3648) ## Summary Auth status checking on the login route was previously handled inside the `LoginView` component using a Redux query, causing a flash of "Checking authentication..." UI within the already-rendered login page. This moves the auth check to a TanStack Router route loader so the redirect to `/workspace` happens before the login page renders, and the pending state is handled cleanly by a dedicated `PendingComponent`. ## Changes - Moved the `is-auth-enabled` auth check from `LoginView` into the `/login` route loader. If auth is disabled or the user already has a valid token, the loader throws a redirect to `/workspace` before the component mounts. - Removed `useIsAuthEnabledQuery`, the `isCheckingAuth` state, and the inline loading UI from `LoginView`, simplifying the component significantly. - Added a `PendingComponent` to the `/login` route that displays the "Checking authentication..." screen while the loader is in flight, with `pendingMs: 0` to show it immediately. - Added `providesTags: ["Sessions"]` to `useIsAuthEnabledQuery` and updated `login` to `invalidatesTags: ["Sessions"]` so session state is properly invalidated after login. Also added `"Sessions"` to the logout invalidation list. ## Type of change - [x] Refactor ## Affected areas - [x] UI (React) ## How to test 1. Navigate to `/login` while unauthenticated — the "Checking authentication..." pending screen should appear briefly, then the login form should render. 2. Navigate to `/login` while already authenticated (valid session cookie) — you should be immediately redirected to `/workspace` without seeing the login form. 3. Navigate to `/login` when auth is disabled — you should be redirected to `/workspace`. 4. Submit valid credentials on the login form — you should be redirected to `/workspace`. ```sh cd ui pnpm i || npm i pnpm build || npm run build ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues #3546 ## Security considerations The auth check now uses `credentials: "include"` in a plain `fetch` call within the route loader, ensuring the session cookie is sent. If the fetch fails, the login page is shown as a safe fallback rather than silently redirecting. ## 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

## Summary Briefly explain the purpose of this PR and the problem it solves. ## Changes - What was changed and why - Any notable design decisions or trade-offs ## 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 Describe the steps to validate this change. Include commands and expected outcomes. ```sh # Core/Transports go version go test ./... # UI cd ui pnpm i || npm i pnpm test || npm test pnpm build || npm run build ``` If adding new configs or environment variables, document them here. ## Screenshots/Recordings If UI changes, add before/after screenshots or short clips. ## Breaking changes - [ ] Yes - [ ] No If yes, describe impact and migration instructions. ## Related issues Link related issues and discussions. Example: Closes #123 ## Security considerations Note any security implications (auth, secrets, PII, sandboxing, etc.). ## 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

## Summary Adds support for Vertex AI's `trafficType` field in `usageMetadata` responses, mapping it to the Bifrost `ServiceTier` abstraction. Previously, only the `serviceTier` field was used, which is specific to the Gemini API. Vertex AI uses a separate `trafficType` field to indicate quota consumption (e.g., on-demand, provisioned throughput). This PR introduces proper handling for both fields and adds a new `provisioned` service tier value. ## Changes - Introduced a typed `TrafficType` constant set covering `ON_DEMAND`, `ON_DEMAND_PRIORITY`, `ON_DEMAND_FLEX`, and `PROVISIONED_THROUGHPUT` values, replacing the previous untyped `string` field on `GenerateContentResponseUsageMetadata`. - Added `mapGeminiTrafficTypeToBifrost` to convert Vertex AI `trafficType` values to `BifrostServiceTier`, returning `nil` for unrecognised or empty values. - Added `mapBifrostServiceTierToVertexTrafficType` to convert `BifrostServiceTier` back to a Vertex AI `TrafficType` for round-trip serialisation. - Updated `ServiceTier` resolution in chat, responses, and streaming paths to prefer `trafficType` over `serviceTier`, falling back to `serviceTier` when `trafficType` is absent or unrecognised. - When serialising back to Gemini/Vertex format, the provider is now checked: Vertex responses use `trafficType`, while Gemini responses continue to use `serviceTier`. - Added `BifrostServiceTierProvisioned` as a new canonical service tier value. ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [x] Core (Go) - [ ] Transports (HTTP) - [x] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test ```sh go test ./... ``` - Send a request through the Vertex AI provider and verify that the returned `ServiceTier` reflects the `trafficType` in the response metadata (e.g., `ON_DEMAND` → `default`, `PROVISIONED_THROUGHPUT` → `provisioned`). - Send a request through the standard Gemini provider and verify that `serviceTier` is still used when `trafficType` is absent. - Verify streaming responses also populate `ServiceTier` correctly on the final chunk. ## Breaking changes - [x] Yes - [ ] No `BifrostServiceTierProvisioned` is a new enum value. Consumers performing exhaustive switches over `BifrostServiceTier` should add a case for `"provisioned"`. ## Related issues ## Security considerations None. ## 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

## Summary `startTime` was being captured inside the goroutine that processes stream chunks, meaning it reflected the time after the HTTP connection was established rather than when the request was actually initiated. This caused time-to-first-chunk and inter-chunk latency metrics to be measured from an incorrect baseline. ## Changes - Moved `startTime := time.Now()` to just before the `client.Do(req, resp)` call in every streaming handler across all providers (Anthropic, Azure, Bedrock, Cohere, Gemini, HuggingFace, Mistral, OpenAI, Replicate, vLLM). - `lastChunkTime` is initialized from `startTime` as before, so relative chunk-to-chunk latency calculations are unaffected — only the absolute start anchor is now correct. ## Type of change - [x] Bug fix ## Affected areas - [x] Core (Go) - [x] Providers/Integrations ## How to test Run the full test suite and exercise any streaming endpoint. Verify that reported time-to-first-chunk values now include network round-trip time to the upstream provider rather than starting the clock only after the connection is fully established. ```sh go test ./... ``` ## Breaking changes - [x] No ## Security considerations None. ## 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

…ss profile assignment (#3560)" (#3669) ## Summary Briefly explain the purpose of this PR and the problem it solves. ## Changes - What was changed and why - Any notable design decisions or trade-offs ## 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 Describe the steps to validate this change. Include commands and expected outcomes. ```sh # Core/Transports go version go test ./... # UI cd ui pnpm i || npm i pnpm test || npm test pnpm build || npm run build ``` If adding new configs or environment variables, document them here. ## Screenshots/Recordings If UI changes, add before/after screenshots or short clips. ## Breaking changes - [ ] Yes - [ ] No If yes, describe impact and migration instructions. ## Related issues Link related issues and discussions. Example: Closes #123 ## Security considerations Note any security implications (auth, secrets, PII, sandboxing, etc.). ## 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

…#3670) ## Summary This PR removes the `access_profile_id` column and its associated index from the `governance_virtual_keys` table, reverting the previously applied `migrationAddVKAccessProfileIDColumn` migration. ## Changes - Added a new migration `migrationDropVKAccessProfileIDColumn` that drops the `idx_governance_virtual_keys_access_profile_id` index and the `access_profile_id` column from `governance_virtual_keys`, if they exist. - Registered the new migration in `triggerMigrations` immediately after the migration that originally added the column, ensuring correct ordering. ## Type of change - [ ] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [x] Chore/CI ## Affected areas - [x] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test ```sh go test ./... ``` Verify that after running migrations, the `governance_virtual_keys` table no longer contains the `access_profile_id` column or its index. Confirm that the migration runs cleanly on both fresh and existing databases where the column may or may not already be present. ## Screenshots/Recordings N/A ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. This change removes an unused column and index with no impact on authentication, secrets, or PII handling. ## 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

…ns, OAuth schema refactor, and new columns (#3671) ## Summary Extends the migration test script to cover v1.5.3 schema changes, including new tables (`feature_flags`, `temp_tokens`) and new columns added across config store and log store tables. Also refactors the per-user OAuth insert generation to handle both the legacy v1.5.0-prerelease4 schema and the v1.5.3 refactored schema, where `oauth_per_user_*` tables were dropped and `oauth_user_sessions`/`oauth_user_tokens` were restructured. ## Changes - Added `generate_feature_flags_insert_postgres` and `generate_feature_flags_insert_sqlite` functions to seed the `feature_flags` table introduced in v1.5.3 via `migrationAddFeatureFlagsTable`. - Added `generate_temp_tokens_insert_postgres` and `generate_temp_tokens_insert_sqlite` functions to seed the `temp_tokens` table introduced in v1.5.3 via `migrationAddTempTokensTable`. - Both new insert generators are wired into `append_dynamic_mcp_clients_insert` for both PostgreSQL and SQLite paths. - Added v1.5.3 dynamic column UPDATE blocks for both PostgreSQL and SQLite covering: - `config_client.metadata_json` - `framework_configs.model_parameters_url` and `config_hash` - `governance_teams.source_id` and `calendar_aligned` - `governance_virtual_keys.access_profile_id` - `logs.cluster_node_id`, `budget_ids`, and `rate_limit_ids` - `mcp_tool_logs.user_id`, `team_id`, `customer_id`, and `business_unit_id` - Refactored `generate_per_user_oauth_tables_insert_postgres` and extracted a new `generate_per_user_oauth_tables_insert_sqlite` function. Both now branch on schema version: if `oauth_per_user_clients` exists, the prerelease4 schema is used; if `oauth_user_sessions.session_id` exists, the v1.5.3 refactored schema (using `session_id` + `flow_mode` instead of `session_token`/`gateway_session_id`) is used instead. ## Type of change - [ ] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [x] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test Run the migration test workflow against a deployment that includes v1.5.3 migrations and verify that the test script seeds all new tables and columns without errors. Also run against a pre-v1.5.3 schema to confirm the conditional guards correctly skip missing tables and columns. ```sh bash .github/workflows/scripts/run-migration-tests.sh ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues Covers migration test coverage for v1.5.3 schema additions. ## Security considerations No new secrets or auth flows are introduced. Test data uses placeholder tokens and hashes that are not used in production. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [ ] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [x] I verified the CI pipeline passes locally if applicable

## Summary This PR addresses two independent improvements: preventing reads on already-closed streaming connections, and tracking which user created a virtual key. ## Changes - Added a `ctx` field to `idleTimeoutReader` so that it can check the `BifrostContextKeyConnectionClosed` flag before attempting a `Read()`. If the connection is already marked as closed, the read returns immediately with `(0, nil)` instead of blocking or erroring. - Added a `CreatedBy` field (`*string`) to `TableVirtualKey` with a database index (`idx_virtual_key_created_by`) to record the creator of each virtual key. ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [x] Core (Go) - [ ] Transports (HTTP) - [x] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test ```sh # Core/Transports go version go test ./... ``` - To validate the idle timeout reader fix: establish a streaming connection, close it, and confirm no further reads are attempted on the closed stream. - To validate the `CreatedBy` field: create a virtual key and confirm the `created_by` column is populated and indexed in the database. ## Screenshots/Recordings N/A ## Breaking changes - [ ] Yes - [x] No ## Related issues N/A ## Security considerations The `CreatedBy` field stores a user identifier on virtual keys. Ensure that this value is not populated with sensitive PII beyond what is already stored in the system, and that access controls on virtual key records remain enforced. ## 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

## Summary Fixes an issue where toast notifications were unclickable when a modal was open. Radix UI's `react-remove-scroll` sets `pointer-events: none` on elements outside the modal, which inadvertently blocked interaction with Sonner toasts. ## Changes - Added a CSS rule to force `pointer-events: auto` on `[data-sonner-toaster]`, ensuring toasts remain interactive even when a modal overlay is active. ## Type of change - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [x] UI (React) - [ ] Docs ## How to test 1. Open any modal dialog in the UI. 2. Trigger a toast notification while the modal is open. 3. Verify the toast is visible and can be clicked/dismissed without closing the modal first. ## Screenshots/Recordings Before: Toasts displayed behind/blocked by modal overlay and could not be clicked. After: Toasts remain fully interactive while a modal is open. ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. ## 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

…rule and virtual key sheets (#3675) ## Summary Cleans up the routing rule sheet UI by removing icon decorations from action buttons and fixing layout issues where the form content doesn't grow to fill available space in both the routing rule and virtual key sheets. ## Changes - Removed the `X` and `Save` icons from the Cancel and Save/Update buttons in the routing rule sheet, leaving text-only labels - Added `grow` and `flex flex-col` classes to the routing rule sheet form and its inner container so the form expands to fill the sheet height correctly - Added `grow` to the virtual key sheet's inner content div for consistent layout behavior - Moved the `RbacOperation`, `RbacResource`, and `useRbac` import to be grouped with other non-local imports ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [x] UI (React) - [ ] Docs ## How to test 1. Open the routing rules sheet (create or edit a rule) and verify the form content fills the full height of the sheet without collapsing. 2. Confirm the Cancel and Save/Update buttons display text only, without icons. 3. Open the virtual key sheet and verify the form content similarly fills the available height. ```sh cd ui pnpm i || npm i pnpm build || npm run build ``` ## Screenshots/Recordings Before/after screenshots showing the button label changes and corrected sheet layout are recommended. ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. ## 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

… and scrollable body (#3676) ## Summary Fixes the Virtual Keys table layout so it fills the available viewport height and scrolls internally, rather than causing the entire page to scroll. The table header remains sticky at the top while the body scrolls, and the pinned action column z-indices are corrected to prevent overlap issues. ## Changes - Converted the outer container to a flex column layout with `grow` and `overflow-hidden` so the table section expands to fill remaining space without overflowing the page. - Added `shrink-0` to the header/toolbar rows so they don't compress when space is constrained. - Made the table container use `min-h-0 grow overflow-hidden` and passed `containerClassName="h-full overflow-auto"` so scrolling is scoped to the table body. - Made `TableHeader` sticky (`sticky top-0 z-20`) with a background so column headers remain visible during vertical scroll. - Adjusted z-index on the pinned right-side `TableHead` to `z-30` (above the sticky header row) and the pinned `TableCell` to `z-20` to maintain correct stacking order. - Reduced pagination text to `text-xs` for visual consistency. ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [x] UI (React) - [ ] Docs ## How to test 1. Navigate to the Virtual Keys page with enough keys to require scrolling. 2. Verify the page itself does not scroll — only the table body scrolls. 3. Verify the column headers remain visible (sticky) as you scroll down. 4. Verify the pinned actions column on the right does not disappear behind the sticky header. 5. Verify row hover states on the pinned actions cell render correctly. ```sh cd ui pnpm i || npm i pnpm build || npm run build ``` ## Screenshots/Recordings Before/after screenshots showing the table scrolling within its container rather than the full page scrolling are recommended. ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. ## 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

## Summary `idleTimeoutReader` had several correctness issues: the cleanup function could return before an in-flight timer callback finished closing the body stream, panics from the underlying reader during a timeout-triggered close were unhandled, a nil context caused a panic, and a closed connection returned `nil` instead of a meaningful error. ## Changes - Added a `timerDone` channel and `timerDoneOnce`/`cleanupOnce` guards so that `cleanup()` blocks until any concurrently running timer callback has fully completed, preventing races between cleanup and the idle timeout close path. - Added a `recover()` deferred in `Read()` that catches panics from the underlying reader (e.g. reads on a closed pipe after timeout) and converts them into `ErrStreamIdleTimeout` or `ErrStreamClosed` rather than crashing. - Extracted `connectionClosed()` and `closedReadError()` helpers to centralise nil-context safety and consistent error selection logic. - Changed the connection-closed early-return in `Read()` to return `ErrStreamClosed` instead of `(0, nil)`, giving callers a clear signal. - Introduced `ErrStreamClosed` as a named sentinel error for streams closed by cancellation or cleanup before a read begins. - Added four new tests covering: nil context safety, closed-context returning `ErrStreamClosed`, panic recovery after timeout, and cleanup blocking until the timer callback finishes. ## Type of change - [x] Bug fix ## Affected areas - [x] Core (Go) ## How to test ```sh go test ./core/providers/utils/... -v -race ``` All four new tests should pass, including `TestIdleTimeoutReader_CleanupWaitsForRunningTimerCallback` which validates the synchronisation behaviour under the race detector. ## Breaking changes - [ ] Yes - [x] No ## Security considerations None. The changes are scoped to internal stream lifecycle management with no impact on auth, secrets, or PII handling. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [ ] I updated documentation where needed - [x] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable

## Summary MCP tool log entries were not being stamped with DAC (Data Access Control) governance ownership fields (`user_id`, `team_id`, `customer_id`, `business_unit_id`) from the request context. This meant MCP logs could not be attributed to the correct organizational entities for governance and auditing purposes. ## Changes - Introduced `applyMCPGovernanceFieldsToEntry`, a helper that reads governance identity fields from the `BifrostContext` and stamps them onto an `MCPToolLog` entry. - Called this helper in both `PreMCPHook` and `PostMCPHook` so that governance fields are applied regardless of whether the log entry originates from a normal pre/post flow or the post-hook fallback path (where no pending pre-hook entry exists). - Added `assertMCPLogGovernanceFields` as a shared test helper to validate all four governance fields on a log entry. - Extended `TestMCPHooksDeferDBWriteUntilPostHookBatch` to set governance context values and assert they are persisted correctly. - Added `TestPostMCPHookFallbackStampsGovernanceFields` to verify that fallback-created MCP log entries (post-hook only, no prior pre-hook) also carry the correct governance fields. ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [ ] Docs ## How to test ```sh go test ./plugins/logging/... -run TestMCPHooksDeferDBWriteUntilPostHookBatch go test ./plugins/logging/... -run TestPostMCPHookFallbackStampsGovernanceFields go test ./plugins/logging/... ``` Both tests should pass. Verify that after a `PreMCPHook` or `PostMCPHook` call with governance context values set, the resulting `MCPToolLog` entry in the store has non-nil `UserID`, `TeamID`, `CustomerID`, and `BusinessUnitID` matching the values placed in the context. ## Screenshots/Recordings N/A ## Breaking changes - [ ] Yes - [x] No ## Related issues N/A ## Security considerations Governance ownership fields (`user_id`, `team_id`, `customer_id`, `business_unit_id`) are sourced exclusively from the authenticated request context and are only written when non-empty, ensuring no unintended data leakage or field overwriting occurs. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [x] 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

The merge-base changed after approval.

CLAassistant · 2026-05-23T20:41:55Z

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
4 out of 8 committers have signed the CLA.

✅ Madhuvod
✅ impoiler
✅ BearTS
✅ Vaibhav701161
❌ TejasGhatte
❌ roroghost17
❌ akshaydeo
❌ dicnunz
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

akshaydeo · 2026-05-25T06:33:04Z

Merge activity

May 25, 6:33 AM UTC: A user started a stack merge that includes this pull request via Graphite.
May 25, 6:33 AM UTC: @akshaydeo merged this pull request with Graphite.

…`values.yaml` (#3612) ## Summary Adds inline documentation comments to the Bifrost Helm chart values for timeout configuration fields, clarifying the units and defaults for rule and provider execution timeouts. ## Changes - Updated the `timeout` comment for guardrail rules to specify seconds as the unit and note the default value of 60 seconds (previously showed `1000`, which was ambiguous in terms of units) - Added a `timeout` comment for guardrail providers to document the default value of 30 seconds ## Type of change - [ ] Bug fix - [ ] Feature - [ ] Refactor - [x] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [x] Docs ## How to test Deploy or lint the Helm chart to confirm the values file renders correctly. ```sh helm lint helm-charts/bifrost ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [x] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable

…`values.yaml` (maximhq#3612) ## Summary Adds inline documentation comments to the Bifrost Helm chart values for timeout configuration fields, clarifying the units and defaults for rule and provider execution timeouts. ## Changes - Updated the `timeout` comment for guardrail rules to specify seconds as the unit and note the default value of 60 seconds (previously showed `1000`, which was ambiguous in terms of units) - Added a `timeout` comment for guardrail providers to document the default value of 30 seconds ## Type of change - [ ] Bug fix - [ ] Feature - [ ] Refactor - [x] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [x] Docs ## How to test Deploy or lint the Helm chart to confirm the values file renders correctly. ```sh helm lint helm-charts/bifrost ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [ ] I added/updated tests where appropriate - [x] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable

akshaydeo force-pushed the dev branch from f036e5f to 5c46934 Compare May 20, 2026 10:00

BearTS force-pushed the 05-20-chore_add_timeout_example_in_providers_yaml_file branch from 06e985b to f4a7c96 Compare May 20, 2026 10:56

BearTS changed the title ~~chore: add timeout example in providers yaml file~~ feat: add timeout comments to guardrail rule and provider entries in values.yaml May 20, 2026

BearTS marked this pull request as ready for review May 20, 2026 10:58

BearTS requested a review from a team as a code owner May 20, 2026 10:58

coderabbitai Bot previously approved these changes May 20, 2026

View reviewed changes

This was referenced May 20, 2026

feat: add access_profile_id support to bifrost helm chart virtual key schema and helpers #3622

Closed

chore: bump Bifrost Helm chart to 2.1.18 with feature flags, model catalog URL, and bug fixes #3623

Merged

BearTS force-pushed the 05-20-chore_add_timeout_example_in_providers_yaml_file branch from f4a7c96 to 0c421c0 Compare May 20, 2026 11:45

greptile-apps Bot reviewed May 20, 2026

View reviewed changes

Comment thread helm-charts/bifrost/values.yaml

BearTS dismissed coderabbitai[bot]’s stale review via d7856f0 May 20, 2026 12:04

BearTS force-pushed the 05-20-chore_add_timeout_example_in_providers_yaml_file branch from 0c421c0 to d7856f0 Compare May 20, 2026 12:04

coderabbitai Bot previously approved these changes May 20, 2026

View reviewed changes

BearTS force-pushed the 05-20-chore_add_timeout_example_in_providers_yaml_file branch from d7856f0 to ce2345a Compare May 20, 2026 17:50

Madhuvod and others added 8 commits May 22, 2026 04:45

BearTS and others added 7 commits May 22, 2026 04:45

akshaydeo force-pushed the dev branch from 3c4d3ae to 6dd1478 Compare May 21, 2026 23:15

akshaydeo added 4 commits May 22, 2026 04:50

v1.5.4 cut (#3680)

249cc51

Merge branch 'main' into dev

78376b2

BearTS force-pushed the 05-20-chore_add_timeout_example_in_providers_yaml_file branch from ce2345a to ed73d93 Compare May 22, 2026 08:20

BearTS mentioned this pull request May 22, 2026

feat: support existingSecret for internal PostgreSQL auth in Bifrost Helm chart #3689

Merged

18 tasks

chore: add timeout example in providers yaml file

73494ef

BearTS force-pushed the 05-20-chore_add_timeout_example_in_providers_yaml_file branch from ed73d93 to 73494ef Compare May 22, 2026 09:41

BearTS mentioned this pull request May 22, 2026

feat: add configurable pod and container security contexts to postgresql deployment #3694

Merged

18 tasks

akshaydeo force-pushed the dev branch from f59c88c to ff463d9 Compare May 22, 2026 15:16

akshaydeo approved these changes May 25, 2026

View reviewed changes

akshaydeo merged commit df41908 into dev May 25, 2026
11 of 13 checks passed

akshaydeo deleted the 05-20-chore_add_timeout_example_in_providers_yaml_file branch May 25, 2026 06:33

coderabbitai Bot mentioned this pull request Jul 8, 2026

[Bug]: MCP client "Tool Execution Timeout" placeholder shows 0 instead of the real global default (30s) #5027

Closed

2 tasks

Navigation Menu

feat: add timeout comments to guardrail rule and provider entries in `values.yaml` - #3612

feat: add timeout comments to guardrail rule and provider entries in `values.yaml`#3612
akshaydeo merged 23 commits into
devfrom
05-20-chore_add_timeout_example_in_providers_yaml_file

BearTS commented May 20, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented May 20, 2026 •

edited

Loading

Rate limit exceeded

Walkthrough

Changes

Estimated code review effort

Poem

Uh oh!

BearTS commented May 20, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented May 20, 2026 •

edited

Loading

Uh oh!

Uh oh!

CLAassistant commented May 23, 2026

Uh oh!

akshaydeo commented May 25, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Conversation

BearTS commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Type of change

Affected areas

How to test

Breaking changes

Related issues

Security considerations

Checklist

Uh oh!

coderabbitai Bot commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rate limit exceeded

Walkthrough

Changes

Estimated code review effort

Poem

Uh oh!

BearTS commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

greptile-apps Bot commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Confidence Score: 4/5

Important Files Changed

Uh oh!

Uh oh!

CLAassistant commented May 23, 2026

Uh oh!

akshaydeo commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge activity

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

BearTS commented May 20, 2026 •

edited

Loading

coderabbitai Bot commented May 20, 2026 •

edited

Loading

BearTS commented May 20, 2026 •

edited

Loading

greptile-apps Bot commented May 20, 2026 •

edited

Loading

akshaydeo commented May 25, 2026 •

edited

Loading