Fix/remote plugin already loaded - #5749
Closed
vvidovic wants to merge 3 commits into
Closed
Conversation
…hq#5705) ## Summary Fixes a Helm schema validation failure introduced in v2.1.32 where multi-profile OTEL configs (`bifrost.plugins.otel.config.profiles`) would fail with `Additional property export_timeout is not allowed`, blocking Helm render and deploy. ## Changes - Added `export_timeout` as an explicitly allowed (but deprecated) property in `values.schema.json` so that Helm's default map merge does not reject values when transitioning from the legacy flat config shape to the `profiles` wrapper shape. - Commented out the `export_timeout: 5` default in `values.yaml` to prevent it from being injected into the config and triggering the schema conflict. - Added a warning to the v2.1.32 changelog directing users to use v2.1.33 instead. - Published the v2.1.33 changelog documenting the fix. - Bumped the Helm chart version to `2.1.33`. ## Type of change - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [ ] Transports (HTTP) - [ ] Providers/Integrations - [x] Plugins - [ ] UI (React) - [x] Docs ## How to test ```sh # Render the Helm chart with a multi-profile OTEL config to confirm schema validation passes helm template bifrost ./helm-charts/bifrost \ --set bifrost.plugins.otel.config.profiles[0].endpoint="http://otel-collector:4318" \ --set bifrost.plugins.otel.config.profiles[0].export_timeout=10 # Should render without errors; previously would fail with: # "Additional property export_timeout is not allowed" ``` ## Breaking changes - [ ] Yes - [x] No ## Related issues Regression introduced in v2.1.32 by the addition of the `export_timeout` default value. ## 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
## Summary
Adds documentation and OpenAPI specs for budget overrides on virtual-key budgets. An override temporarily raises a budget's effective spending limit by adding an `override_amount` on top of the base `max_limit`, without touching the base limit, current usage, or reset schedule. Overrides can be granted for a finite number of reset cycles or indefinitely, and are managed via `PUT`/`DELETE` on `/api/governance/virtual-keys/{vk_id}/budgets/{budget_id}/override`.
## Changes
- Added a **Budget overrides** section to `budget-and-limits.mdx` explaining the `effective_max_limit = max_limit + override_amount` enforcement model and linking to the virtual keys walkthrough.
- Expanded the override section in `virtual-keys.mdx` with full API usage examples for `PUT` (both `cycles` and `forever` modes) and `DELETE`, a sample JSON response, and behavioral notes covering immutability of the base limit, cycle anchoring, and cluster consistency.
- Registered `PUT` and `DELETE` endpoints for `/api/governance/virtual-keys/{vk_id}/budgets/{budget_id}/override` in the OpenAPI spec (both JSON and YAML), including request/response schemas (`BudgetOverrideRequest`, `BudgetOverrideResponse`) and new override fields on the `Budget` schema (`override_amount`, `override_mode`, `override_cycles_remaining`, `override_cycles_total`, `override_anchor_reset`).
## 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
1. Navigate to the **Budget overrides** section in `budget-and-limits.mdx` and confirm the formula and cross-link render correctly.
2. Navigate to the override API section in `virtual-keys.mdx` and verify all code blocks, the sample response, and the behavioral notes display as expected.
3. Load the OpenAPI spec and confirm the two new endpoints appear under the **Governance** tag with correct request/response schemas and that the `Budget` schema includes the five new override fields.
## Breaking changes
- [ ] Yes
- [x] No
## Related issues
## Security considerations
The new endpoints require `ManagementBearerAuth`, consistent with all other governance management endpoints. No new auth surface is introduced.
## 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
fix(framework/plugins): prevent "plugin already loaded" on remote plugin update When a custom plugin loaded from a remote URL was updated via the API (e.g. config change, enable/disable), Bifrost re-downloaded the same .so bytes, wrote them to a new temp path, and called plugin.Open again. Go's plugin system treats any plugin binary with the same checksum as already loaded, failing with "plugin already loaded". Fix uses SHA-256 content hash as the stable on-disk filename and an in-memory cache keyed by content hash (not URL): - DownloadPlugin (utils.go): computes SHA-256 while streaming the response body, derives the stable path as /tmp/bifrost-plugin-<hash>.so, and atomically renames the temp file to it. Subsequent downloads of the same content return the existing stable path from cache with no file I/O. - openPlugin (soloader.go): after download, checks the in-memory cache. If cached.loadedPlugin != nil, returns it directly — plugin.Open is skipped entirely. This is the key fix: the same binary is only opened once. - DynamicPlugin (soplugin.go): added contentHash field to track the binary's SHA-256. - Removed 3 tests (soplugin_test.go) that attempted to load the same plugin binary twice in a single test process. This triggers Go's "plugin already loaded" error and is unsupported — plugins are loaded once per process. Fixes maximhq#5741.
|
|
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (19)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe change adds virtual-key budget override API contracts and documentation, content-hash caching for remote plugins, Helm 2.1.33 OTEL schema updates, and Docker volume configuration for SQLite stores and the user-info plugin. ChangesVirtual-key budget overrides
Content-hash plugin caching
Helm 2.1.33 correction
Docker volume configuration
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
Suggested reviewers: ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.12.2)level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies" 🔧 oasdiff (1.26.0)docs/openapi/openapi.yamlError: failed to load base spec from "/tmp/coderabbit-oasdiff-base.GtdVHi": encountered disallowed external reference: "./paths/inference/async.yaml#/components/parameters/AsyncJobId" Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Warning |
Author
|
|
This was referenced Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a "plugin already loaded" error when updating a custom plugin loaded from a remote URL. When a remote plugin was updated (e.g. config change, enable/disable), Bifrost re-downloaded the same .so bytes, wrote them to a new temp path, and called
plugin.Openagain. Go's plugin system treats any binary with the same checksum as already loaded, failing with "plugin already loaded".Changes
framework/plugins/utils.go:
DownloadPluginnow computes SHA-256 of plugin bytes during download, derives a stable path as/tmp/bifrost-plugin-<hash>.so, and atomically renames the temp file. Subsequent downloads of identical content return the existing stable path from an in-memory cache with no file I/O.framework/plugins/soloader.go: After download,
openPluginchecks the in-memory cache. Ifcached.loadedPlugin != nil, the cached*plugin.Pluginis returned directly —plugin.Openis skipped entirely. This is the core fix: the same binary content is only opened once per process.framework/plugins/soplugin.go: Added
contentHashfield toDynamicPluginto track the binary's SHA-256.framework/plugins/soplugin_test.go: Removed 3 tests (
TestLoadPlugin_CacheHitSkipsOpen,TestLoadPlugin_ConfigUpdateReusesPlugin,TestLoadPlugin_ContentChangeLoadsNewPlugin) that attempted to load the same plugin binary twice in a single test process. Go's plugin system does not support unloading or re-loading a module, so these tests were testing unsupported behavior.Type of change
Affected areas
How to test
Describe the steps to validate this change. Include commands and expected outcomes.