feat: plugin context added#3
Closed
Pratham-Mishra04 wants to merge 1 commit into03-21-feat_plugin_interface_and_tests_addedfrom
Closed
feat: plugin context added#3Pratham-Mishra04 wants to merge 1 commit into03-21-feat_plugin_interface_and_tests_addedfrom
Pratham-Mishra04 wants to merge 1 commit into03-21-feat_plugin_interface_and_tests_addedfrom
Conversation
Collaborator
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
danpiths
reviewed
Mar 22, 2025
| type Plugin interface { | ||
| PreHook(req *BifrostRequest) (*BifrostRequest, error) | ||
| PostHook(result *CompletionResult) (*CompletionResult, error) | ||
| PreHook(ctx *context.Context, req *BifrostRequest) (*BifrostRequest, error) |
Collaborator
There was a problem hiding this comment.
let us pass in the context object and not a pointer to the context for both the pre and post hook
danpiths
reviewed
Mar 22, 2025
|
|
||
| req, err = plugin.PreHook(req) | ||
| // Create a context with timeout same as the provider/request config | ||
| ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) |
Collaborator
There was a problem hiding this comment.
we will not create our own context, we shall ask users to pass in the context from the chat/text completion functions. keep it as the first param there. they would pass in their context to the completion functions that we shall use with in the plugin system
This was referenced Mar 31, 2025
thiscantbeserious
added a commit
to thiscantbeserious/bifrost
that referenced
this pull request
Apr 17, 2026
CodeRabbit round 2:
10. /models query-param fallback now checks for existing client_version
before injecting. Preserves caller-supplied params like foo=bar and
picks up caller's own client_version when present. Uses simple
string split (no net/url allocation) since paths are well-formed.
11. chatGPTOAuthWebSocketHeaders now routes through
mergeHeadersCaseInsensitive so caller-supplied headers with
different casing (OPENAI-BETA, Openai-Beta, etc.) can't cause
duplicate-case headers reaching the wire — OAuth values and the
Authorization bearer always win deterministically.
Greptile findings:
P1 maximhq#1 Non-streaming Responses() path: return a clear BifrostOperationError
pointing callers to ResponsesStream when chatgpt_oauth is on.
The ChatGPT backend only accepts stream=true (matching the
openai-oauth reference proxy behavior), so non-streaming cannot
work via Bifrost without server-side SSE aggregation which is
out of scope for this PR. In practice Codex always streams.
P1 maximhq#2 /models response format: OpenAIListModelsResponse now has a
UnmarshalJSON that accepts BOTH the standard OpenAI shape
({"data":[{id,...}]}) and the ChatGPT backend shape
({"models":[{slug}]}). ChatGPT entries are projected into
OpenAIModel with ID=slug, Object="model", OwnedBy="chatgpt-oauth".
P2 maximhq#3 client_version doc comment: corrected — the fallback only
applies when the inbound path reaches chatGPTOAuthPath without
a caller-supplied client_version (previously the doc implied
forwarding logic that didn't exist; it now does).
P2 maximhq#4 store doc comment: corrected from "sets store to false if not
already present" to "forces store to false" to match the code
and explanation.
P2 maximhq#5 Double JWT decode per Responses/ResponsesStream: fixed by
passing raw networkConfig.ExtraHeaders to chatGPTOAuthApplyRequest
instead of the already-merged effectiveExtraHeaders(key). The
merge now happens exactly once per call.
Test coverage: 100% on every function in chatgpt_oauth.go. Added tests
for query-param preservation, models dual-shape parsing, and the
streaming-only sentinel error.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ALSEDLAH
pushed a commit
to ALSEDLAH/bifrost
that referenced
this pull request
Apr 20, 2026
/speckit-clarify session recording 4 integrated decisions. All mechanical consequences applied inline. Q1 — US14 Prompt Library: **Split.** Basic prompt library (templates, variables, folders, versioning) is IN SCOPE, already satisfied by the re-enabled upstream `plugins/prompts/` in Phase 1 T012. Deployment-strategies subset (A/B, canary, production pointer) is DESCOPED — new extension of the prompts plugin, needs its own spec. SR-01 table gets a US14-deployments row in the out-of-scope column. FR-029/030/031 marked ALREADY_SHIPPED; FR-029 note covers the deployment-strategy split. US14 story header and CI whitelist already align. Q2 — Audit actor attribution in v1: **Synthetic "upstream-admin".** No session→user middleware yet. All admin actions reach handlers via the single upstream basic-auth credential, so audit entries carry `actor_type="system"`, `actor_id="upstream-admin"` — self-documenting, matches reality. `handlers/rbac_audit.go` updated; FR-010 annotated. When proper middleware lands in a future spec, `emitAudit` callers need no change. Verified live on :8088 — latest role.delete entry shows the new attribution. Q3 — v1 RBAC server-side enforcement: **UI-only.** `useRbac` hides UI controls; no server-side scope check today. Adding a server enforcement layer is net-new with no upstream precedent (same SR-01 class as admin API keys) and belongs in its own spec. FR-003 and FR-004 annotated; FR-004 resource list corrected from "29" to "24" (matching `framework/tenancy/scopes.go`). Limitation already documented in `docs/enterprise/rbac.mdx` §"Notes & limits". Q4 — Audit store location: **Configstore** (not logstore). Rows are semantically closer to `ent_roles`/`ent_users`; single SQLite file simpler for self-hosted deployments. Plugin doc comment in `plugins/audit/main.go` updated to match shipped reality; `docs/enterprise/audit-logs.mdx` already said "configuration database" (no change). FR-012 annotated, including the explicit note that automatic retention cleanup is out of v1 scope — rows accumulate until cleanup SQL is run or a retention task ships. Session used 4 of 5 questions; remaining potential items are stylistic and don't change architecture or test design. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ALSEDLAH
pushed a commit
to ALSEDLAH/bifrost
that referenced
this pull request
Apr 20, 2026
/speckit-clarify session recording 4 integrated decisions. All mechanical consequences applied inline. Q1 — US14 Prompt Library: **Split.** Basic prompt library (templates, variables, folders, versioning) is IN SCOPE, already satisfied by the re-enabled upstream `plugins/prompts/` in Phase 1 T012. Deployment-strategies subset (A/B, canary, production pointer) is DESCOPED — new extension of the prompts plugin, needs its own spec. SR-01 table gets a US14-deployments row in the out-of-scope column. FR-029/030/031 marked ALREADY_SHIPPED; FR-029 note covers the deployment-strategy split. US14 story header and CI whitelist already align. Q2 — Audit actor attribution in v1: **Synthetic "upstream-admin".** No session→user middleware yet. All admin actions reach handlers via the single upstream basic-auth credential, so audit entries carry `actor_type="system"`, `actor_id="upstream-admin"` — self-documenting, matches reality. `handlers/rbac_audit.go` updated; FR-010 annotated. When proper middleware lands in a future spec, `emitAudit` callers need no change. Verified live on :8088 — latest role.delete entry shows the new attribution. Q3 — v1 RBAC server-side enforcement: **UI-only.** `useRbac` hides UI controls; no server-side scope check today. Adding a server enforcement layer is net-new with no upstream precedent (same SR-01 class as admin API keys) and belongs in its own spec. FR-003 and FR-004 annotated; FR-004 resource list corrected from "29" to "24" (matching `framework/tenancy/scopes.go`). Limitation already documented in `docs/enterprise/rbac.mdx` §"Notes & limits". Q4 — Audit store location: **Configstore** (not logstore). Rows are semantically closer to `ent_roles`/`ent_users`; single SQLite file simpler for self-hosted deployments. Plugin doc comment in `plugins/audit/main.go` updated to match shipped reality; `docs/enterprise/audit-logs.mdx` already said "configuration database" (no change). FR-012 annotated, including the explicit note that automatic retention cleanup is out of v1 scope — rows accumulate until cleanup SQL is run or a retention task ships. Session used 4 of 5 questions; remaining potential items are stylistic and don't change architecture or test design.
22 tasks
thiscantbeserious
added a commit
to thiscantbeserious/bifrost
that referenced
this pull request
Apr 24, 2026
CodeRabbit round 2:
10. /models query-param fallback now checks for existing client_version
before injecting. Preserves caller-supplied params like foo=bar and
picks up caller's own client_version when present. Uses simple
string split (no net/url allocation) since paths are well-formed.
11. chatGPTOAuthWebSocketHeaders now routes through
mergeHeadersCaseInsensitive so caller-supplied headers with
different casing (OPENAI-BETA, Openai-Beta, etc.) can't cause
duplicate-case headers reaching the wire — OAuth values and the
Authorization bearer always win deterministically.
Greptile findings:
P1 maximhq#1 Non-streaming Responses() path: return a clear BifrostOperationError
pointing callers to ResponsesStream when chatgpt_oauth is on.
The ChatGPT backend only accepts stream=true (matching the
openai-oauth reference proxy behavior), so non-streaming cannot
work via Bifrost without server-side SSE aggregation which is
out of scope for this PR. In practice Codex always streams.
P1 maximhq#2 /models response format: OpenAIListModelsResponse now has a
UnmarshalJSON that accepts BOTH the standard OpenAI shape
({"data":[{id,...}]}) and the ChatGPT backend shape
({"models":[{slug}]}). ChatGPT entries are projected into
OpenAIModel with ID=slug, Object="model", OwnedBy="chatgpt-oauth".
P2 maximhq#3 client_version doc comment: corrected — the fallback only
applies when the inbound path reaches chatGPTOAuthPath without
a caller-supplied client_version (previously the doc implied
forwarding logic that didn't exist; it now does).
P2 maximhq#4 store doc comment: corrected from "sets store to false if not
already present" to "forces store to false" to match the code
and explanation.
P2 maximhq#5 Double JWT decode per Responses/ResponsesStream: fixed by
passing raw networkConfig.ExtraHeaders to chatGPTOAuthApplyRequest
instead of the already-merged effectiveExtraHeaders(key). The
merge now happens exactly once per call.
Test coverage: 100% on every function in chatgpt_oauth.go. Added tests
for query-param preservation, models dual-shape parsing, and the
streaming-only sentinel error.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
akshaydeo
pushed a commit
that referenced
this pull request
Apr 28, 2026
… rules instead of halting (#3082) ## Summary Fixes a bug where a routing rule chain would incorrectly halt when a `chain_rule=true` rule resolved to the same provider/model as the current context (a self-loop). Previously, this was treated as a cycle and stopped chain evaluation immediately. Now, each rule is tracked by its ID rather than by the resulting provider/model state, allowing a self-looping rule to fire once and then be skipped so subsequent rules in the chain can continue to evaluate. ## Changes - Replaced provider/model state-based cycle detection (`visited` map keyed on `provider|model`) with rule ID-based tracking (`visitedRuleIDs` map keyed on `rule.ID`). Each rule may now fire at most once per chain evaluation, regardless of whether its target matches the current state. - A self-looping chain rule (one that resolves to the same provider/model it was invoked with) now fires once and is then skipped, allowing lower-priority rules to match on subsequent chain steps. - Updated termination condition #3 in the `EvaluateRoutingRules` documentation to reflect that the chain stops when all candidate chain-rules have already fired, rather than when a previously visited provider/model state is encountered. - Renamed `TestEvaluateRoutingRules_ConvergenceStopsChain` to `TestEvaluateRoutingRules_SelfLoopContinuesToNextRule` and updated it to assert that a self-looping rule correctly yields to the next matching rule. - Added `TestEvaluateRoutingRules_SelfLoopAloneTerminates` to verify that a self-looping chain rule with no other rules terminates cleanly via the "no remaining rule matches" condition. ## Type of change - [x] Bug fix - [ ] 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/governance/... -run TestEvaluateRoutingRules_SelfLoop go test ./plugins/governance/... ``` Expected: `TestEvaluateRoutingRules_SelfLoopContinuesToNextRule` passes, asserting the chain resolves to `anthropic/claude-3` after the self-looping rule fires once. `TestEvaluateRoutingRules_SelfLoopAloneTerminates` passes, asserting the chain resolves to `openai/gpt-4o` and terminates cleanly. ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations None. ## 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
ryan-orphic
added a commit
to Orphic-AI/bifrost
that referenced
this pull request
May 4, 2026
…output tool
Bedrock Converse rejects toolConfig.toolChoice.tool on Meta Llama variants
with HTTP 400 ("This model doesn't support the toolConfig.toolChoice.tool
field. Remove toolConfig.toolChoice.tool and try again."). The synthetic
bf_so_* tool path used for structured output unconditionally pinned the
synthetic tool via toolChoice.tool, which broke every with_structured_output
caller against Llama 4 Maverick / Scout / Llama 3.x on Bedrock.
This patch adds an IsLlamaModel helper next to the existing IsNovaModel /
IsAnthropicModel family and gates the forced-tool emission off it in four
places (covering both API surfaces and both the synthetic and explicit
tool_choice paths on each):
1. core/providers/bedrock/utils.go: ChatCompletions synthetic-tool injection
(response_format=json_schema -> bf_so_* tool path).
2. core/providers/bedrock/responses.go: OpenAI Responses API mirror of maximhq#1
(text.format=json_schema -> bf_so_* tool path).
3. core/providers/bedrock/utils.go: convertToolConfigFromFiltered's explicit
tool_choice path (defense-in-depth for ChatCompletions callers using
bind_tools(tool_choice={"type": "function", "function": {"name": "X"}})
directly).
4. core/providers/bedrock/responses.go: Responses API mirror of maximhq#3 — the
explicit tool_choice path runs convertResponsesToolChoice and writes
BedrockToolChoice{Tool: ...} straight onto the request, which trips the
same Llama 400 without the gate.
With one synthetic tool bound and Bedrock's default "auto" behavior, omitting
tool_choice yields the same outcome on Llama because there's exactly one tool
the model can call. This mirrors the gate langchain-aws ships
(supports_tool_choice_values for llama4 / llama3-1 / llama3-3 sets only
"auto", causing with_structured_output to emit no tool_choice at all).
Tests added (mirroring PR maximhq#3184's TestBedrockAnthropicChatStructuredOutputUsesSyntheticTool
naming and structure):
- TestBedrockLlamaChatStructuredOutputOmitsForcedToolChoice — synthetic tool
present, ToolChoice nil for Llama on the ChatCompletions path.
- TestBedrockNonLlamaChatStructuredOutputForcesToolChoice — regression guard:
Nova / Anthropic still get the forced tool_choice (gate doesn't over-fire).
- TestToBedrockResponsesRequest_LlamaStructuredOutputOmitsForcedToolChoice —
same negative+positive on the Responses API synthetic-tool path.
- TestBedrockLlamaConvertToolConfigOmitsForcedToolChoice — defense-in-depth
coverage for ChatCompletions explicit tool_choice struct callers.
- TestToBedrockResponsesRequest_LlamaConvertResponsesToolChoiceOmitsForcedToolChoice
— defense-in-depth coverage for Responses API explicit tool_choice
(function-typed) struct callers — the gap surfaced in code review.
- TestToBedrockResponsesRequest_NonLlamaConvertResponsesToolChoiceForcesToolChoice
— Anthropic regression guard for maximhq#5 so the Responses-side Llama gate
doesn't over-fire.
Refs:
- https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ToolChoice.html
- https://github.com/langchain-ai/langchain-aws (bedrock_converse.py
supports_tool_choice_values family-detection lines 678-711).
- PR maximhq#3184 (Anthropic structured-output fallback to synthetic tool path) —
immediate predecessor; this PR completes the per-family gating story.
akshaydeo
pushed a commit
that referenced
this pull request
May 4, 2026
…output tool (#3196) Bedrock Converse rejects toolConfig.toolChoice.tool on Meta Llama variants with HTTP 400 ("This model doesn't support the toolConfig.toolChoice.tool field. Remove toolConfig.toolChoice.tool and try again."). The synthetic bf_so_* tool path used for structured output unconditionally pinned the synthetic tool via toolChoice.tool, which broke every with_structured_output caller against Llama 4 Maverick / Scout / Llama 3.x on Bedrock. This patch adds an IsLlamaModel helper next to the existing IsNovaModel / IsAnthropicModel family and gates the forced-tool emission off it in four places (covering both API surfaces and both the synthetic and explicit tool_choice paths on each): 1. core/providers/bedrock/utils.go: ChatCompletions synthetic-tool injection (response_format=json_schema -> bf_so_* tool path). 2. core/providers/bedrock/responses.go: OpenAI Responses API mirror of #1 (text.format=json_schema -> bf_so_* tool path). 3. core/providers/bedrock/utils.go: convertToolConfigFromFiltered's explicit tool_choice path (defense-in-depth for ChatCompletions callers using bind_tools(tool_choice={"type": "function", "function": {"name": "X"}}) directly). 4. core/providers/bedrock/responses.go: Responses API mirror of #3 — the explicit tool_choice path runs convertResponsesToolChoice and writes BedrockToolChoice{Tool: ...} straight onto the request, which trips the same Llama 400 without the gate. With one synthetic tool bound and Bedrock's default "auto" behavior, omitting tool_choice yields the same outcome on Llama because there's exactly one tool the model can call. This mirrors the gate langchain-aws ships (supports_tool_choice_values for llama4 / llama3-1 / llama3-3 sets only "auto", causing with_structured_output to emit no tool_choice at all). Tests added (mirroring PR #3184's TestBedrockAnthropicChatStructuredOutputUsesSyntheticTool naming and structure): - TestBedrockLlamaChatStructuredOutputOmitsForcedToolChoice — synthetic tool present, ToolChoice nil for Llama on the ChatCompletions path. - TestBedrockNonLlamaChatStructuredOutputForcesToolChoice — regression guard: Nova / Anthropic still get the forced tool_choice (gate doesn't over-fire). - TestToBedrockResponsesRequest_LlamaStructuredOutputOmitsForcedToolChoice — same negative+positive on the Responses API synthetic-tool path. - TestBedrockLlamaConvertToolConfigOmitsForcedToolChoice — defense-in-depth coverage for ChatCompletions explicit tool_choice struct callers. - TestToBedrockResponsesRequest_LlamaConvertResponsesToolChoiceOmitsForcedToolChoice — defense-in-depth coverage for Responses API explicit tool_choice (function-typed) struct callers — the gap surfaced in code review. - TestToBedrockResponsesRequest_NonLlamaConvertResponsesToolChoiceForcesToolChoice — Anthropic regression guard for #5 so the Responses-side Llama gate doesn't over-fire. Refs: - https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ToolChoice.html - https://github.com/langchain-ai/langchain-aws (bedrock_converse.py supports_tool_choice_values family-detection lines 678-711). - PR #3184 (Anthropic structured-output fallback to synthetic tool path) — immediate predecessor; this PR completes the per-family gating story.
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
2 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.
No description provided.