refactor: standardize embedding response format across providers#214
Conversation
Summary by CodeRabbit
WalkthroughThis update refactors embedding response handling by removing provider-specific response structs and unifying them under a common Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 4
🔭 Outside diff range comments (2)
core/providers/azure.go (2)
75-86: Fix inconsistent text response pool methodsThe
acquireAzureTextResponseandreleaseAzureTextResponsemethods still useAzureTextResponsetype, but the pool itself has been changed to useschemas.BifrostResponse. This will cause a type mismatch.// acquireAzureTextResponse gets an Azure text completion response from the pool and resets it. -func acquireAzureTextResponse() *AzureTextResponse { - resp := azureTextCompletionResponsePool.Get().(*AzureTextResponse) - *resp = AzureTextResponse{} // Reset the struct +func acquireAzureTextResponse() *schemas.BifrostResponse { + resp := azureTextCompletionResponsePool.Get().(*schemas.BifrostResponse) + *resp = schemas.BifrostResponse{} // Reset the struct return resp } // releaseAzureTextResponse returns an Azure text completion response to the pool. -func releaseAzureTextResponse(resp *AzureTextResponse) { +func releaseAzureTextResponse(resp *schemas.BifrostResponse) { if resp != nil { azureTextCompletionResponsePool.Put(resp) } }
238-291: Update TextCompletion to use unified response handlingThe
TextCompletionmethod still uses the old pattern withAzureTextResponse, which is inconsistent with the pool changes and will cause runtime errors. It should be updated to useschemas.BifrostResponsedirectly like theChatCompletionandEmbeddingmethods.The method should:
- Use
acquireAzureChatResponse()instead ofacquireAzureTextResponse()- Let
handleProviderResponsepopulate the response- Set provider metadata on
response.ExtraFields- Return the response directly without manual construction
This would align with the standardized approach used in other methods.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (13)
core/providers/azure.go(4 hunks)core/providers/bedrock.go(2 hunks)core/providers/cohere.go(1 hunks)core/providers/mistral.go(1 hunks)core/providers/openai.go(2 hunks)core/schemas/bifrost.go(2 hunks)transports/bifrost-http/integrations/openai/types.go(2 hunks)transports/bifrost-http/plugins/logging/main.go(2 hunks)transports/bifrost-http/plugins/logging/models.go(1 hunks)transports/bifrost-http/plugins/telemetry/main.go(1 hunks)transports/go.mod(1 hunks)ui/components/logs/log-detail-sheet.tsx(1 hunks)ui/lib/types/logs.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (44)
📓 Common learnings
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#169
File: docs/usage/http-transport/openapi.json:1352-1358
Timestamp: 2025-07-17T08:56:59.907Z
Learning: In the Bifrost project, the fallback format has been updated from object structure {"provider": "...", "model": "..."} to a simpler string format "provider/model" (e.g., "anthropic/claude-3-sonnet-20240229"). The current OpenAPI schema correctly reflects this new format.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#212
File: transports/bifrost-http/integrations/openai/types.go:250-288
Timestamp: 2025-08-04T22:19:12.975Z
Learning: In transports/bifrost-http/integrations/openai/types.go, the ConvertToBifrostRequest function for OpenAIEmbeddingRequest handles []interface{} input without validation for non-string elements because Pratham-Mishra04 confirmed this case will never happen in practice, consistent with their preference to avoid defensive programming for unreachable scenarios.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#162
File: transports/bifrost-http/integrations/genai/types.go:0-0
Timestamp: 2025-07-16T07:13:29.496Z
Learning: Pratham-Mishra04 prefers to avoid redundant error handling across architectural layers in the Bifrost streaming implementation. When error handling (such as timeouts, context cancellation, and JSON marshaling failures) is already handled at the provider level, they prefer not to duplicate this logic at the transport integration layer to keep the code simple and avoid unnecessary complexity.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#196
File: core/providers/openai.go:180-183
Timestamp: 2025-07-29T16:10:52.088Z
Learning: In the Bifrost provider architecture, `handleProviderResponse` is a utility function that only parses and returns raw response data when the `sendBackRawResponse` flag is true. It's the responsibility of each individual provider (OpenAI, Anthropic, etc.) to conditionally set `response.ExtraFields.RawResponse` using the returned raw response data based on their `sendBackRawResponse` flag. This represents a separation of concerns where the utility handles parsing and the provider handles response object construction.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#202
File: transports/bifrost-http/plugins/governance/resolver.go:183-191
Timestamp: 2025-08-03T20:36:21.906Z
Learning: In the Bifrost governance plugin (transports/bifrost-http/plugins/governance/resolver.go), Pratham-Mishra04 considers the current string matching approach for determining rate limit violation decision types (DecisionTokenLimited vs DecisionRequestLimited) adequate and not important enough to refactor with more robust explicit checks, preferring functional simplicity over theoretical robustness improvements.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#202
File: transports/bifrost-http/handlers/governance.go:1038-1049
Timestamp: 2025-08-03T20:28:00.857Z
Learning: In the Bifrost governance handler (transports/bifrost-http/handlers/governance.go), Pratham-Mishra04 is comfortable with exposing full error details including err.Error() in production responses for governance API endpoints, prioritizing simplicity over potential information disclosure concerns.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#141
File: core/bifrost.go:198-272
Timestamp: 2025-07-08T18:30:08.258Z
Learning: Pratham-Mishra04 follows a pattern of implementing core functionality first and deferring non-critical improvements (like race condition fixes, optimizations) to later PRs. This is a reasonable development approach that prioritizes getting the main feature working before addressing edge cases.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:358-388
Timestamp: 2025-06-04T05:37:59.699Z
Learning: User Pratham-Mishra04 prefers not to extract small code duplications (around 2 lines) into helper functions, considering the overhead not worth it for such minor repetition.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#102
File: README.md:62-66
Timestamp: 2025-06-19T17:03:03.639Z
Learning: Pratham-Mishra04 prefers using the implicit 'latest' tag for the maximhq/bifrost Docker image rather than pinning to specific versions.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#143
File: core/mcp.go:155-196
Timestamp: 2025-07-08T15:33:47.698Z
Learning: Pratham-Mishra04 prefers not to add explanatory comments for obvious code patterns, such as the unlock/lock strategy around network I/O operations, considering them self-explanatory to experienced developers.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#150
File: transports/bifrost-http/lib/store.go:370-466
Timestamp: 2025-07-09T04:58:08.229Z
Learning: Pratham-Mishra04 prefers not to add logging or error handling for unreachable code paths in the Bifrost project. When provider types or similar entities are predefined in the system, defensive programming like logging in default cases is considered unnecessary overhead.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#138
File: docs/usage/go-package/mcp.md:408-412
Timestamp: 2025-07-01T12:40:08.576Z
Learning: Pratham-Mishra04 is okay with keeping bullet list formatting that uses colons after dashes in markdown documentation, even if it triggers linter warnings, preferring functionality over strict formatting rules.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#162
File: tests/core-providers/scenarios/chat_completion_stream.go:103-105
Timestamp: 2025-07-16T04:26:09.288Z
Learning: Pratham-Mishra04 prefers to keep test code simple when it serves its basic functional purpose. For tests that are meant to validate core functionality (like verifying streaming works), they consider hard-coded reasonable limits acceptable rather than making them configurable.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#148
File: transports/bifrost-http/lib/store.go:880-910
Timestamp: 2025-07-08T17:14:21.544Z
Learning: Pratham-Mishra04 prefers resilient system design where missing environment variables for MCP connections should not cause complete system failure. The system should continue processing other MCP connections even when some fail, maintaining partial functionality rather than implementing fail-fast behavior.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#148
File: transports/bifrost-http/lib/store.go:1081-1098
Timestamp: 2025-07-08T17:16:50.811Z
Learning: Pratham-Mishra04 prefers practical redaction approaches over theoretical security improvements when the threat model is low-risk, such as admin-only interfaces in the Bifrost project. Fixed-length redaction is acceptable when only trusted administrators will see the redacted values.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#138
File: transports/README.md:26-28
Timestamp: 2025-07-01T12:45:06.906Z
Learning: Pratham-Mishra04 prefers keeping documentation examples simple and concise, trusting users to handle production-specific considerations like version pinning themselves rather than cluttering examples with additional notes.
📚 Learning: in transports/bifrost-http/integrations/openai/types.go, the converttobifrostrequest function for op...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#212
File: transports/bifrost-http/integrations/openai/types.go:250-288
Timestamp: 2025-08-04T22:19:12.975Z
Learning: In transports/bifrost-http/integrations/openai/types.go, the ConvertToBifrostRequest function for OpenAIEmbeddingRequest handles []interface{} input without validation for non-string elements because Pratham-Mishra04 confirmed this case will never happen in practice, consistent with their preference to avoid defensive programming for unreachable scenarios.
Applied to files:
transports/bifrost-http/plugins/telemetry/main.gocore/providers/cohere.gocore/providers/bedrock.goui/lib/types/logs.tscore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gotransports/bifrost-http/plugins/logging/main.gocore/providers/azure.gocore/schemas/bifrost.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the json parser plugin (plugins/jsonparser/main.go), the posthook method is designed with a contr...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#209
File: plugins/jsonparser/plugin_test.go:38-45
Timestamp: 2025-08-04T19:39:39.417Z
Learning: In the JSON Parser plugin (plugins/jsonparser/main.go), the PostHook method is designed with a contract that guarantees the response structure (Choices, BifrostStreamResponseChoice, Delta, Content) will always be present when called, making defensive nil checks unnecessary in tests.
Applied to files:
transports/bifrost-http/plugins/telemetry/main.gocore/schemas/bifrost.go
📚 Learning: in core/bifrost.go, the count parameter in runposthooks method is intentionally kept separate from p...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#79
File: core/bifrost.go:94-103
Timestamp: 2025-06-14T04:06:58.240Z
Learning: In core/bifrost.go, the count parameter in RunPostHooks method is intentionally kept separate from p.executedPreHooks to support circuit breaker plugins that may need to trigger PostHooks for only a subset of executed plugins when detecting failure conditions mid-execution.
Applied to files:
transports/bifrost-http/plugins/telemetry/main.go
📚 Learning: the bifrost codebase uses string alias types (like `type contextkey string`) for context keys consis...
Learnt from: connyay
PR: maximhq/bifrost#92
File: core/providers/utils.go:60-64
Timestamp: 2025-06-17T14:04:21.104Z
Learning: The bifrost codebase uses string alias types (like `type ContextKey string`) for context keys consistently across multiple packages including plugins/maxim/main.go and transports/bifrost-http/tracking/plugin.go. This pattern should be maintained for consistency rather than switching to the canonical struct{} approach.
Applied to files:
transports/bifrost-http/plugins/telemetry/main.gotransports/bifrost-http/integrations/openai/types.gotransports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in core/schemas/bifrost.go, the requestinput struct uses chatcompletioninput *[]bifrostmessage (poin...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/bifrost.go:46-49
Timestamp: 2025-06-04T09:22:18.123Z
Learning: In core/schemas/bifrost.go, the RequestInput struct uses ChatCompletionInput *[]BifrostMessage (pointer-to-slice) rather than []BifrostMessage to properly represent union type semantics. For text completion requests, ChatCompletionInput should be nil to indicate "no chat payload at all", while for chat completion requests it should be non-nil (even if empty slice). This distinguishes between different request types rather than just empty vs non-empty chat messages.
Applied to files:
transports/bifrost-http/plugins/telemetry/main.gocore/providers/cohere.gocore/providers/bedrock.gocore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gotransports/bifrost-http/plugins/logging/main.gocore/providers/azure.gocore/schemas/bifrost.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost provider architecture, `handleproviderresponse` is a utility function that only parse...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#196
File: core/providers/openai.go:180-183
Timestamp: 2025-07-29T16:10:52.088Z
Learning: In the Bifrost provider architecture, `handleProviderResponse` is a utility function that only parses and returns raw response data when the `sendBackRawResponse` flag is true. It's the responsibility of each individual provider (OpenAI, Anthropic, etc.) to conditionally set `response.ExtraFields.RawResponse` using the returned raw response data based on their `sendBackRawResponse` flag. This represents a separation of concerns where the utility handles parsing and the provider handles response object construction.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/providers/openai.gocore/providers/azure.gocore/providers/mistral.go
📚 Learning: in core/providers/anthropic.go, the content field in formattedmessages is always of type []interface...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:526-550
Timestamp: 2025-06-04T09:29:46.287Z
Learning: In core/providers/anthropic.go, the content field in formattedMessages is always of type []interface{} because it's explicitly constructed that way upstream in the prepareAnthropicChatRequest function. Defensive type casting for multiple types is not needed since the type is guaranteed by the construction logic.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost project, the fallback format has been updated from object structure {"provider": "......
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#169
File: docs/usage/http-transport/openapi.json:1352-1358
Timestamp: 2025-07-17T08:56:59.907Z
Learning: In the Bifrost project, the fallback format has been updated from object structure {"provider": "...", "model": "..."} to a simpler string format "provider/model" (e.g., "anthropic/claude-3-sonnet-20240229"). The current OpenAPI schema correctly reflects this new format.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.goui/lib/types/logs.tscore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/schemas/bifrost.gocore/providers/mistral.go
📚 Learning: for cohere v1 api in core/providers/cohere.go, the tool_choice parameter formatting uses uppercase s...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/cohere.go:327-335
Timestamp: 2025-06-15T13:46:24.869Z
Learning: For Cohere v1 API in core/providers/cohere.go, the tool_choice parameter formatting uses uppercase strings for the "type" field (e.g., "AUTO", "TOOL") and follows a different structure than initially assumed. The current implementation with strings.ToUpper() for the type field is correct for the v1 API.
Applied to files:
core/providers/cohere.go
📚 Learning: in bifrost core v1.0.9, imagecontent.type was a pointer type (*string accessed via bifrost.ptr), but...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/types.go:140-146
Timestamp: 2025-06-10T13:51:52.859Z
Learning: In Bifrost core v1.0.9, ImageContent.Type was a pointer type (*string accessed via bifrost.Ptr), but in v1.0.10 it was changed to a value type (ImageContentType). When reviewing code, check the core version being used to determine the correct assignment pattern.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gotransports/bifrost-http/integrations/openai/types.gotransports/bifrost-http/plugins/logging/main.gocore/schemas/bifrost.gotransports/go.modtransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost codebase, performance is prioritized over defensive copying for http service operatio...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/providers/azure.gocore/schemas/bifrost.gocore/providers/mistral.gotransports/go.mod
📚 Learning: in the bifrost project, breaking api changes are acceptable when features are not yet public. this a...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#144
File: transports/bifrost-http/handlers/providers.go:45-49
Timestamp: 2025-07-08T16:50:27.699Z
Learning: In the Bifrost project, breaking API changes are acceptable when features are not yet public. This applies to scenarios like changing struct fields from pointer to non-pointer types in request/response structures for unreleased features.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gotransports/bifrost-http/integrations/openai/types.gotransports/bifrost-http/plugins/logging/main.gocore/schemas/bifrost.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: when json unmarshaling into pooled structs, slice fields like `choices []schemas.bifrostresponsechoi...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#88
File: core/providers/mistral.go:170-176
Timestamp: 2025-06-16T06:56:55.290Z
Learning: When JSON unmarshaling into pooled structs, slice fields like `Choices []schemas.BifrostResponseChoice` get fresh heap memory allocations from `json.Unmarshal()`. The slice data is not part of the pooled struct's memory, so defensive copying is unnecessary. Resetting pooled structs with `*resp = ResponseType{}` only clears slice headers, not the underlying data.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/providers/openai.gocore/providers/azure.gocore/schemas/bifrost.gocore/providers/mistral.go
📚 Learning: in the bifrosterror struct, the error field is a struct (not a pointer), so accessing bifrosterr.err...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#80
File: plugins/maxim/main.go:249-264
Timestamp: 2025-06-14T06:17:54.426Z
Learning: In the BifrostError struct, the Error field is a struct (not a pointer), so accessing bifrostErr.Error.Message, bifrostErr.Error.Code, and bifrostErr.Error.Type is safe without nil checks on the Error field itself. The Code and Type fields are of type *string.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gotransports/bifrost-http/integrations/openai/types.gotransports/bifrost-http/plugins/logging/main.gocore/providers/azure.gocore/schemas/bifrost.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the genericrouter (transports/bifrost-http/integrations), responsefunc is not called if the bifro...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/router.go:19-33
Timestamp: 2025-06-09T16:46:32.018Z
Learning: In the GenericRouter (transports/bifrost-http/integrations), ResponseFunc is not called if the BifrostResponse parameter is nil, providing built-in protection against nil response marshaling.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/providers/azure.gocore/schemas/bifrost.go
📚 Learning: in the bifrost codebase, errors returned from client methods like chatcompletionrequest are of type ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/end_to_end_tool_calling.go:43-45
Timestamp: 2025-06-16T04:13:55.437Z
Learning: In the Bifrost codebase, errors returned from client methods like ChatCompletionRequest are of type BifrostError, not the standard error interface. For testing these errors, use require.Nilf instead of require.NoErrorf since BifrostError doesn't work with the standard error assertion methods.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/schemas/bifrost.gocore/providers/mistral.gotransports/go.mod
📚 Learning: in the bifrost codebase, errors returned from methods like chatcompletionrequest are of type bifrost...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/simple_chat.go:39-41
Timestamp: 2025-06-16T04:13:42.755Z
Learning: In the Bifrost codebase, errors returned from methods like ChatCompletionRequest are of type BifrostError (a custom error type) rather than the standard Go error interface. Therefore, require.Nilf should be used for error assertions instead of require.NoErrorf.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/schemas/bifrost.gocore/providers/mistral.gotransports/go.mod
📚 Learning: in the bifrost project, bifrostconfig struct is never marshaled/unmarshaled, so serialization tags (...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/schemas/bifrost.go:20-23
Timestamp: 2025-06-18T15:16:23.127Z
Learning: In the Bifrost project, BifrostConfig struct is never marshaled/unmarshaled, so serialization tags (json, yaml) are not needed for its fields.
Applied to files:
core/providers/cohere.gocore/providers/bedrock.gocore/schemas/bifrost.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in core/providers/bedrock.go, for tool call result messages (modelchatmessageroletool), the content ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/bedrock.go:443-468
Timestamp: 2025-06-04T09:32:15.826Z
Learning: In core/providers/bedrock.go, for tool call result messages (ModelChatMessageRoleTool), the Content field represents the actual tool call output. A tool result message should only be created when msg.Content is non-nil, as there's no semantic meaning to a tool result without output content.
Applied to files:
core/providers/bedrock.gotransports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: breaking changes in the bifrost codebase are managed by first merging and tagging core schema change...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Applied to files:
core/providers/bedrock.gocore/schemas/bifrost.go
📚 Learning: in bedrock provider tool result handling, json arrays must be wrapped in a content object like {"con...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/bedrock.go:441-469
Timestamp: 2025-06-04T04:20:55.609Z
Learning: In Bedrock provider tool result handling, JSON arrays must be wrapped in a content object like {"content": [...]} while other JSON types are passed directly. This is a Bedrock-specific requirement that differs from other providers.
Applied to files:
core/providers/bedrock.go
📚 Learning: in the bifrost system, error returns are of type `bifrosterror` rather than the standard go `error` ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/complete_end_to_end.go:39-41
Timestamp: 2025-06-16T04:12:05.427Z
Learning: In the Bifrost system, error returns are of type `BifrostError` rather than the standard Go `error` interface. Therefore, use `require.Nilf(t, err, ...)` instead of `require.NoError(t, err)` when checking for errors in Bifrost function calls.
Applied to files:
core/providers/bedrock.gotransports/go.mod
📚 Learning: in the bifrost schema (core/schemas/bifrost.go), only usermessage and toolmessage structs have image...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#64
File: transports/bifrost-http/integrations/genai/types.go:383-395
Timestamp: 2025-06-09T16:26:05.777Z
Learning: In the Bifrost schema (core/schemas/bifrost.go), only UserMessage and ToolMessage structs have ImageContent fields. AssistantMessage does not have an ImageContent field and cannot contain images. The schema design intentionally limits image content to user and tool messages only.
Applied to files:
core/providers/bedrock.gotransports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost openai integration (transports/bifrost-http/integrations/openai/types.go), the conver...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
Applied to files:
core/providers/openai.gotransports/bifrost-http/integrations/openai/types.go
📚 Learning: in transports/bifrost-http/integrations/genai/types.go, when systeminstruction has an empty role, th...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#89
File: transports/bifrost-http/integrations/genai/types.go:151-155
Timestamp: 2025-06-16T14:45:48.563Z
Learning: In transports/bifrost-http/integrations/genai/types.go, when SystemInstruction has an empty role, the user prefers to let the downstream provider (Google GenAI) handle validation and return errors, rather than implementing validation in the bifrost layer. This represents a design preference for delegating validation to the appropriate service rather than duplicating validation logic in the proxy layer.
Applied to files:
core/providers/openai.gocore/providers/mistral.go
📚 Learning: in the google genai integration at transports/bifrost-http/integrations/genai/types.go, the manual u...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#89
File: transports/bifrost-http/integrations/genai/types.go:22-56
Timestamp: 2025-06-16T14:50:46.859Z
Learning: In the Google GenAI integration at transports/bifrost-http/integrations/genai/types.go, the manual URL-safe base64 decoding implementation (converting - to +, _ to /, and adding padding) is required because base64.RawURLEncoding.DecodeString fails for the specific url encoded bytes format being handled.
Applied to files:
core/providers/openai.gotransports/bifrost-http/integrations/openai/types.gotransports/go.mod
📚 Learning: in transports/bifrost-http/handlers/completions.go, for speech completion requests, the user prefers...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#177
File: transports/bifrost-http/handlers/completions.go:248-264
Timestamp: 2025-07-22T12:14:08.826Z
Learning: In transports/bifrost-http/handlers/completions.go, for speech completion requests, the user prefers to let the provider handle ResponseFormat validation rather than validating supported audio formats ("mp3", "opus", "aac", "flac") at the HTTP transport layer. This follows the architectural pattern of delegating domain-specific validation to providers rather than duplicating validation logic in the transport layer.
Applied to files:
core/providers/openai.gocore/providers/azure.gocore/schemas/bifrost.gocore/providers/mistral.go
📚 Learning: in core/schemas/bifrost.go, the toolchoice unmarshaljson validation intentionally only checks for em...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/schemas/bifrost.go:186-190
Timestamp: 2025-06-15T14:18:32.703Z
Learning: In core/schemas/bifrost.go, the ToolChoice UnmarshalJSON validation intentionally only checks for empty Type fields and lets providers handle validation of specific tool choice values. This architectural decision keeps schema validation focused on structure while allowing provider-specific semantic validation.
Applied to files:
core/providers/openai.gotransports/bifrost-http/plugins/logging/main.gocore/schemas/bifrost.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: the chatcompletionrequest method in the bifrost client follows a contract where the result parameter...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/utils.go:169-173
Timestamp: 2025-06-09T17:33:52.234Z
Learning: The ChatCompletionRequest method in the Bifrost client follows a contract where the result parameter will never be nil if the error parameter is nil. This means when error checking passes (err == nil), the result is guaranteed to be valid and can be safely used without additional nil checks.
Applied to files:
core/providers/openai.gocore/providers/azure.gocore/providers/mistral.go
📚 Learning: the openai `name` field on messages cannot be preserved when converting to bifrost format because th...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:223-231
Timestamp: 2025-06-10T11:06:06.670Z
Learning: The OpenAI `name` field on messages cannot be preserved when converting to Bifrost format because the `schemas.BifrostMessage` struct in bifrost/core does not support a Name field. This is a known limitation of the Bifrost core schema design.
Applied to files:
transports/bifrost-http/integrations/openai/types.gocore/schemas/bifrost.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost logging system (transports/bifrost-http/plugins/logging/utils.go), the content field ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#144
File: transports/bifrost-http/plugins/logging/utils.go:509-514
Timestamp: 2025-07-08T16:48:25.386Z
Learning: In the Bifrost logging system (transports/bifrost-http/plugins/logging/utils.go), the Content field in message structures is a struct value type, not a pointer, so it will never be nil and doesn't require nil checks. However, ContentStr within Content is a pointer and should be checked for nil.
Applied to files:
transports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), pratham-mishra04 p...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#152
File: transports/bifrost-http/plugins/logging/utils.go:16-18
Timestamp: 2025-07-10T13:44:39.237Z
Learning: In the Bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), Pratham-Mishra04 prefers to ignore JSON marshaling errors when storing log entries because logging is not critical for their use case and they are certain the marshaling operations won't fail.
Applied to files:
transports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), pratham-mishra04 p...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#152
File: transports/bifrost-http/plugins/logging/utils.go:378-399
Timestamp: 2025-07-10T13:44:14.518Z
Learning: In the Bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), Pratham-Mishra04 prefers not to add error handling for JSON unmarshaling operations, considering logging not very critical and being confident that JSON marshalling won't fail in practice.
Applied to files:
transports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: pratham-mishra04 prefers not to add error handling for json marshaling operations in the bifrost log...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#152
File: transports/bifrost-http/plugins/logging/utils.go:94-111
Timestamp: 2025-07-10T13:44:23.297Z
Learning: Pratham-Mishra04 prefers not to add error handling for JSON marshaling operations in the Bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go) because logging is not critical functionality and the structured schema data being marshaled is unlikely to fail. They accept the risk of not handling json.Marshal errors in logging contexts to keep the code simple.
Applied to files:
transports/bifrost-http/plugins/logging/main.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/models.go
📚 Learning: in the bifrost repository's transport dependency update workflow, when updating the core dependency ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Applied to files:
transports/bifrost-http/plugins/logging/main.gotransports/go.mod
📚 Learning: go 1.23 introduced the ability to range over integers. the syntax `for range n` where n is an intege...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: core/providers/ollama.go:68-72
Timestamp: 2025-06-15T14:31:59.649Z
Learning: Go 1.23 introduced the ability to range over integers. The syntax `for range n` where n is an integer will iterate from 0 to n-1, making `for range config.ConcurrencyAndBufferSize.Concurrency` valid syntax for iterating a specific number of times without needing an explicit counter variable.
Applied to files:
core/providers/azure.go
📚 Learning: go 1.22 introduced the ability to range over integers. the syntax `for range n` where n is an intege...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: core/providers/ollama.go:68-72
Timestamp: 2025-06-15T14:31:59.649Z
Learning: Go 1.22 introduced the ability to range over integers. The syntax `for range n` where n is an integer will iterate from 0 to n-1, making `for range config.ConcurrencyAndBufferSize.Concurrency` valid syntax for iterating a specific number of times without needing an explicit counter variable. This feature requires Go module version 1.22 or later.
Applied to files:
core/providers/azure.go
📚 Learning: pratham-mishra04 prefers to avoid redundant error handling across architectural layers in the bifros...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#162
File: transports/bifrost-http/integrations/genai/types.go:0-0
Timestamp: 2025-07-16T07:13:29.496Z
Learning: Pratham-Mishra04 prefers to avoid redundant error handling across architectural layers in the Bifrost streaming implementation. When error handling (such as timeouts, context cancellation, and JSON marshaling failures) is already handled at the provider level, they prefer not to duplicate this logic at the transport integration layer to keep the code simple and avoid unnecessary complexity.
Applied to files:
core/providers/mistral.go
📚 Learning: the `core-providers-test` module in `tests/core-providers/` is an internal testing module that will ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/go.mod:38-38
Timestamp: 2025-06-16T03:54:48.005Z
Learning: The `core-providers-test` module in `tests/core-providers/` is an internal testing module that will never be consumed as a dependency by external projects, so the replace directive pointing to `../../core` is acceptable for local development and testing purposes.
Applied to files:
transports/go.mod
📚 Learning: in go, when importing a package, the identifier used to access it is determined by the `package` dec...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.462Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
Applied to files:
transports/go.mod
📚 Learning: in go module files, `go 1.24.1` (with patch version) can work fine in some setups, contrary to the g...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/go.mod:3-4
Timestamp: 2025-06-16T04:27:53.538Z
Learning: In Go module files, `go 1.24.1` (with patch version) can work fine in some setups, contrary to the general rule that go directives should only include major.minor versions.
Applied to files:
transports/go.mod
📚 Learning: in the bifrost project, the user prefers to use `package main` for test files in the tests/core-prov...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/openai_test.go:1-2
Timestamp: 2025-06-16T04:29:53.409Z
Learning: In the Bifrost project, the user prefers to use `package main` for test files in the tests/core-providers directory rather than more descriptive package names like `coreproviders_test`.
Applied to files:
transports/go.mod
📚 Learning: in the bifrost test suite (tests/core-providers), parallel tests using t.parallel() are not being im...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/automatic_function_calling.go:22-22
Timestamp: 2025-06-16T04:55:11.886Z
Learning: In the Bifrost test suite (tests/core-providers), parallel tests using t.Parallel() are not being implemented currently. The team plans to add parallel test execution in future enhancements.
Applied to files:
transports/go.mod
🧬 Code Graph Analysis (8)
transports/bifrost-http/plugins/telemetry/main.go (2)
ui/components/ui/input.tsx (1)
Input(7-22)core/schemas/bifrost.go (1)
EmbeddingInput(66-68)
core/providers/cohere.go (1)
core/schemas/bifrost.go (2)
BifrostEmbedding(493-497)BifrostEmbeddingResponse(499-503)
core/providers/bedrock.go (2)
core/schemas/bifrost.go (2)
BifrostEmbedding(493-497)BifrostEmbeddingResponse(499-503)ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
ui/lib/types/logs.ts (1)
core/schemas/bifrost.go (1)
BifrostEmbedding(493-497)
transports/bifrost-http/integrations/openai/types.go (3)
core/schemas/bifrost.go (2)
BifrostEmbedding(493-497)LLMUsage(390-396)ui/lib/types/logs.ts (2)
BifrostEmbedding(110-114)LLMUsage(176-182)plugins/mocker/main.go (1)
Usage(138-142)
transports/bifrost-http/plugins/logging/main.go (2)
core/schemas/bifrost.go (1)
BifrostEmbedding(493-497)ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
core/schemas/bifrost.go (1)
ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
transports/bifrost-http/plugins/logging/models.go (2)
core/schemas/bifrost.go (1)
BifrostEmbedding(493-497)ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
🔇 Additional comments (17)
transports/go.mod (1)
19-19: LGTM - Standard local development pattern.The replace directive correctly points to the local core module, ensuring the transports module uses the updated embedding response format during development. This aligns with the PR's objective to standardize embedding responses across providers.
ui/components/logs/log-detail-sheet.tsx (1)
242-246: LGTM - Correctly adapts to new embedding structure.The change properly extracts the
embeddingfield from eachBifrostEmbeddingobject, maintaining the same visual representation while adapting to the new structured embedding format introduced in the core schema.transports/bifrost-http/plugins/logging/models.go (1)
48-48: LGTM - Type update aligns with new embedding structure.The change from
*[][]float32to*[]schemas.BifrostEmbeddingcorrectly updates the logging model to support the new structured embedding format, ensuring consistency with the core schema changes.transports/bifrost-http/plugins/telemetry/main.go (1)
62-63: LGTM - Extends telemetry to support embedding requests.The addition follows the established pattern for request type detection and enables proper method classification for embedding requests in Prometheus metrics, completing coverage for all supported request types.
ui/lib/types/logs.ts (2)
110-114: LGTM - New embedding interface provides flexible structure.The
BifrostEmbeddinginterface correctly implements the new structured embedding format with flexible typing for theembeddingfield (string | number[] | number[][]), matching the backend schema definition incore/schemas/bifrost.go.
226-226: LGTM - LogEntry updated to use structured embedding type.The change from
number[][]toBifrostEmbedding[]correctly aligns the frontend types with the new backend embedding structure, ensuring type safety and consistency across the system.transports/bifrost-http/plugins/logging/main.go (2)
44-44: LGTM: Field type updated to use standardized embedding format.The change from
*[][]float32to*[]schemas.BifrostEmbeddingcorrectly aligns with the unified embedding response structure introduced in this PR.
519-521: LGTM: Assignment updated to use new Data field.The change from
result.Embeddingtoresult.Datacorrectly reflects the new embedding response structure where embedding data is now stored in theDatafield ofBifrostResponse.core/providers/mistral.go (1)
243-265: LGTM: Clean refactor to use unified response handling.The changes successfully replace provider-specific embedding response handling with the standardized approach:
- Uses pooled
schemas.BifrostResponsefor better performance- Delegates parsing to the shared
handleProviderResponseutility function- Properly sets provider metadata and handles raw response data
- Eliminates duplicate parsing logic across providers
This aligns perfectly with the PR objective to standardize embedding response format across all providers.
core/providers/bedrock.go (2)
1174-1180: LGTM! Correctly implements the new standardized embedding format.The changes properly wrap the Titan embedding response in the new
BifrostEmbeddingstructure within theDataslice. The single-dimensional embedding is correctly converted to 2D format by wrapping it in an outer slice, maintaining consistency with theBifrostEmbeddingResponse.Embedding2DArrayfield type.
1234-1242: LGTM! Proper adaptation of Cohere embedding response format.The changes correctly implement the standardized embedding format for Cohere models. Since Cohere already returns 2D embeddings (
[][]float32), using a pointer to the existingcohereResp.Embeddingsin theEmbedding2DArrayfield is efficient and appropriate. The preservation of theIDfield maintains compatibility.transports/bifrost-http/integrations/openai/types.go (2)
99-105: LGTM! Correctly adopts the standardized embedding type.The struct now uses
[]schemas.BifrostEmbeddinginstead of a local embedding type, which aligns with the standardization effort across all providers. This eliminates code duplication and ensures consistent embedding response handling.
430-430: LGTM! Simplified conversion function with correct field references.The changes properly update the nil check to target
bifrostResp.Dataand directly assign the standardized embedding data. This simplification eliminates manual construction overhead and aligns with the new unified embedding response structure.Also applies to: 436-436
core/providers/openai.go (1)
302-324: LGTM! Clean refactoring to unified response formatThe refactoring successfully standardizes the embedding response handling by:
- Using the pooled
schemas.BifrostResponseinstead of provider-specific types- Delegating response parsing to the shared
handleProviderResponseutility- Properly setting provider metadata on the response
This aligns perfectly with the PR objective of unifying embedding response format across providers.
core/providers/azure.go (2)
311-331: LGTM! Properly unified response handlingThe
ChatCompletionmethod correctly implements the unified response format by:
- Using the pooled
schemas.BifrostResponse- Setting provider metadata directly on
response.ExtraFields- Returning the response without manual construction
This is consistent with the standardized approach.
365-386: LGTM! Consistent embedding response handlingThe
Embeddingmethod properly implements the unified response format, following the same pattern as the OpenAI provider. The reuse ofacquireAzureChatResponsefor embeddings is appropriate since both now use the genericschemas.BifrostResponse.core/schemas/bifrost.go (1)
493-497: LGTM! Well-designed embedding structureThe
BifrostEmbeddingstruct provides a clean abstraction that:
- Aligns with provider response formats (especially OpenAI's "data" array)
- Maintains index and object metadata
- Uses the flexible
BifrostEmbeddingResponsefor various embedding formatsThis design successfully unifies embedding responses across all providers.
af601ac to
78284a9
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (3)
core/providers/openai.go (1)
28-32: Remove the unusedDatafield fromOpenAIResponseThis field is no longer used after the refactoring to use
schemas.BifrostResponsedirectly in theEmbeddingmethod. The entire embedding logic now uses the pooled response structure.type OpenAIResponse struct { ID string `json:"id"` Object string `json:"object"` Choices []schemas.BifrostResponseChoice `json:"choices"` - Data []struct { // Embedding data - Object string `json:"object"` - Embedding any `json:"embedding"` // can be []float32 or string - Index int `json:"index"` - } `json:"data,omitempty"` Model string `json:"model"` Created int `json:"created"` ServiceTier *string `json:"service_tier"` SystemFingerprint *string `json:"system_fingerprint"` Usage schemas.LLMUsage `json:"usage"` }core/schemas/bifrost.go (2)
505-516: Improve error message in MarshalJSONThe error message "no embedding found" could be more descriptive to help with debugging.
- return nil, fmt.Errorf("no embedding found") + return nil, fmt.Errorf("BifrostEmbeddingResponse: all embedding fields are nil")
526-538: Fix incorrect comments in UnmarshalJSONThe comments mention "ContentBlock" which appears to be a copy-paste error from another unmarshal method.
- // Try to unmarshal as a direct array of ContentBlock + // Try to unmarshal as a direct array of float32 var arrayContent []float32 if err := sonic.Unmarshal(data, &arrayContent); err == nil { be.EmbeddingArray = &arrayContent return nil } - // Try to unmarshal as a direct 2D array of ContentBlock + // Try to unmarshal as a direct 2D array of float32 var arrayContent2D [][]float32 if err := sonic.Unmarshal(data, &arrayContent2D); err == nil { be.Embedding2DArray = &arrayContent2D return nil }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
transports/go.sumis excluded by!**/*.sum
📒 Files selected for processing (13)
core/providers/azure.go(4 hunks)core/providers/bedrock.go(2 hunks)core/providers/cohere.go(1 hunks)core/providers/mistral.go(1 hunks)core/providers/openai.go(2 hunks)core/schemas/bifrost.go(2 hunks)transports/bifrost-http/integrations/openai/types.go(2 hunks)transports/bifrost-http/plugins/logging/main.go(2 hunks)transports/bifrost-http/plugins/logging/models.go(1 hunks)transports/bifrost-http/plugins/telemetry/main.go(1 hunks)transports/go.mod(1 hunks)ui/components/logs/log-detail-sheet.tsx(1 hunks)ui/lib/types/logs.ts(2 hunks)
🧰 Additional context used
🧠 Learnings (53)
📓 Common learnings
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#169
File: docs/usage/http-transport/openapi.json:1352-1358
Timestamp: 2025-07-17T08:56:59.907Z
Learning: In the Bifrost project, the fallback format has been updated from object structure {"provider": "...", "model": "..."} to a simpler string format "provider/model" (e.g., "anthropic/claude-3-sonnet-20240229"). The current OpenAPI schema correctly reflects this new format.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#212
File: transports/bifrost-http/integrations/openai/types.go:250-288
Timestamp: 2025-08-04T22:19:12.975Z
Learning: In transports/bifrost-http/integrations/openai/types.go, the ConvertToBifrostRequest function for OpenAIEmbeddingRequest handles []interface{} input without validation for non-string elements because Pratham-Mishra04 confirmed this case will never happen in practice, consistent with their preference to avoid defensive programming for unreachable scenarios.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: transports/bifrost-http/main.go:2-2
Timestamp: 2025-06-15T16:05:13.489Z
Learning: For the Bifrost project, HTTP transport integration routers for new providers (like Mistral and Ollama) are implemented in separate PRs from the core provider support, following a focused PR strategy.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#162
File: transports/bifrost-http/integrations/genai/types.go:0-0
Timestamp: 2025-07-16T07:13:29.496Z
Learning: Pratham-Mishra04 prefers to avoid redundant error handling across architectural layers in the Bifrost streaming implementation. When error handling (such as timeouts, context cancellation, and JSON marshaling failures) is already handled at the provider level, they prefer not to duplicate this logic at the transport integration layer to keep the code simple and avoid unnecessary complexity.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#150
File: transports/bifrost-http/lib/store.go:370-466
Timestamp: 2025-07-09T04:58:08.229Z
Learning: Pratham-Mishra04 prefers not to add logging or error handling for unreachable code paths in the Bifrost project. When provider types or similar entities are predefined in the system, defensive programming like logging in default cases is considered unnecessary overhead.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#158
File: .github/workflows/transports-release.yml:30-43
Timestamp: 2025-07-18T11:12:28.861Z
Learning: Pratham-Mishra04 relies on branch protection rules and mandatory code reviews for security in the bifrost repository, preferring process controls over technical security measures like environment variable isolation for GitHub Actions workflows. All commits are reviewed before merging to main branch.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#141
File: core/bifrost.go:198-272
Timestamp: 2025-07-08T18:30:08.258Z
Learning: Pratham-Mishra04 follows a pattern of implementing core functionality first and deferring non-critical improvements (like race condition fixes, optimizations) to later PRs. This is a reasonable development approach that prioritizes getting the main feature working before addressing edge cases.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#202
File: transports/bifrost-http/plugins/governance/resolver.go:183-191
Timestamp: 2025-08-03T20:36:21.906Z
Learning: In the Bifrost governance plugin (transports/bifrost-http/plugins/governance/resolver.go), Pratham-Mishra04 considers the current string matching approach for determining rate limit violation decision types (DecisionTokenLimited vs DecisionRequestLimited) adequate and not important enough to refactor with more robust explicit checks, preferring functional simplicity over theoretical robustness improvements.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#202
File: transports/bifrost-http/handlers/governance.go:1038-1049
Timestamp: 2025-08-03T20:28:00.857Z
Learning: In the Bifrost governance handler (transports/bifrost-http/handlers/governance.go), Pratham-Mishra04 is comfortable with exposing full error details including err.Error() in production responses for governance API endpoints, prioritizing simplicity over potential information disclosure concerns.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#196
File: core/providers/openai.go:180-183
Timestamp: 2025-07-29T16:10:52.088Z
Learning: In the Bifrost provider architecture, `handleProviderResponse` is a utility function that only parses and returns raw response data when the `sendBackRawResponse` flag is true. It's the responsibility of each individual provider (OpenAI, Anthropic, etc.) to conditionally set `response.ExtraFields.RawResponse` using the returned raw response data based on their `sendBackRawResponse` flag. This represents a separation of concerns where the utility handles parsing and the provider handles response object construction.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/bifrost.go:823-845
Timestamp: 2025-06-18T15:15:51.323Z
Learning: In the Bifrost project, the team prioritizes maintaining consistent error handling patterns over exposing detailed error context. All errors should be wrapped in the standard `BifrostError` structure rather than creating specific error types or exposing richer error details like exit codes or stderr output.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#144
File: transports/bifrost-http/handlers/providers.go:45-49
Timestamp: 2025-07-08T16:50:27.699Z
Learning: In the Bifrost project, breaking API changes are acceptable when features are not yet public. This applies to scenarios like changing struct fields from pointer to non-pointer types in request/response structures for unreleased features.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/router.go:0-0
Timestamp: 2025-06-09T14:03:34.227Z
Learning: In the Bifrost HTTP transport layer (transports/bifrost-http/integrations/), request validation like checking for empty messages should be handled by the provider rather than at the transport layer. The transport layer should forward requests to Bifrost core/providers for validation.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/types.go:131-180
Timestamp: 2025-06-10T13:11:37.867Z
Learning: In Anthropic API integration for Bifrost, messages won't contain both image and tool_result content blocks in the same message, so defensive guards against multiple embedded message structs are unnecessary in the content processing loop.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:358-388
Timestamp: 2025-06-04T05:37:59.699Z
Learning: User Pratham-Mishra04 prefers not to extract small code duplications (around 2 lines) into helper functions, considering the overhead not worth it for such minor repetition.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#102
File: README.md:62-66
Timestamp: 2025-06-19T17:03:03.639Z
Learning: Pratham-Mishra04 prefers using the implicit 'latest' tag for the maximhq/bifrost Docker image rather than pinning to specific versions.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#143
File: core/mcp.go:155-196
Timestamp: 2025-07-08T15:33:47.698Z
Learning: Pratham-Mishra04 prefers not to add explanatory comments for obvious code patterns, such as the unlock/lock strategy around network I/O operations, considering them self-explanatory to experienced developers.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#138
File: docs/usage/go-package/mcp.md:408-412
Timestamp: 2025-07-01T12:40:08.576Z
Learning: Pratham-Mishra04 is okay with keeping bullet list formatting that uses colons after dashes in markdown documentation, even if it triggers linter warnings, preferring functionality over strict formatting rules.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#162
File: tests/core-providers/scenarios/chat_completion_stream.go:103-105
Timestamp: 2025-07-16T04:26:09.288Z
Learning: Pratham-Mishra04 prefers to keep test code simple when it serves its basic functional purpose. For tests that are meant to validate core functionality (like verifying streaming works), they consider hard-coded reasonable limits acceptable rather than making them configurable.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#148
File: transports/bifrost-http/lib/store.go:880-910
Timestamp: 2025-07-08T17:14:21.544Z
Learning: Pratham-Mishra04 prefers resilient system design where missing environment variables for MCP connections should not cause complete system failure. The system should continue processing other MCP connections even when some fail, maintaining partial functionality rather than implementing fail-fast behavior.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#138
File: transports/README.md:26-28
Timestamp: 2025-07-01T12:45:06.906Z
Learning: Pratham-Mishra04 prefers keeping documentation examples simple and concise, trusting users to handle production-specific considerations like version pinning themselves rather than cluttering examples with additional notes.
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#148
File: transports/bifrost-http/lib/store.go:1081-1098
Timestamp: 2025-07-08T17:16:50.811Z
Learning: Pratham-Mishra04 prefers practical redaction approaches over theoretical security improvements when the threat model is low-risk, such as admin-only interfaces in the Bifrost project. Fixed-length redaction is acceptable when only trusted administrators will see the redacted values.
📚 Learning: in transports/bifrost-http/integrations/openai/types.go, the converttobifrostrequest function for op...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#212
File: transports/bifrost-http/integrations/openai/types.go:250-288
Timestamp: 2025-08-04T22:19:12.975Z
Learning: In transports/bifrost-http/integrations/openai/types.go, the ConvertToBifrostRequest function for OpenAIEmbeddingRequest handles []interface{} input without validation for non-string elements because Pratham-Mishra04 confirmed this case will never happen in practice, consistent with their preference to avoid defensive programming for unreachable scenarios.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/telemetry/main.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/main.goui/lib/types/logs.tscore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in core/schemas/bifrost.go, the requestinput struct uses chatcompletioninput *[]bifrostmessage (poin...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/bifrost.go:46-49
Timestamp: 2025-06-04T09:22:18.123Z
Learning: In core/schemas/bifrost.go, the RequestInput struct uses ChatCompletionInput *[]BifrostMessage (pointer-to-slice) rather than []BifrostMessage to properly represent union type semantics. For text completion requests, ChatCompletionInput should be nil to indicate "no chat payload at all", while for chat completion requests it should be non-nil (even if empty slice). This distinguishes between different request types rather than just empty vs non-empty chat messages.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/telemetry/main.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/main.gocore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in bifrost core v1.0.9, imagecontent.type was a pointer type (*string accessed via bifrost.ptr), but...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/types.go:140-146
Timestamp: 2025-06-10T13:51:52.859Z
Learning: In Bifrost core v1.0.9, ImageContent.Type was a pointer type (*string accessed via bifrost.Ptr), but in v1.0.10 it was changed to a value type (ImageContentType). When reviewing code, check the core version being used to determine the correct assignment pattern.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/go.modtransports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/integrations/openai/types.gocore/providers/bedrock.gocore/schemas/bifrost.go
📚 Learning: in the bifrost logging system (transports/bifrost-http/plugins/logging/utils.go), the content field ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#144
File: transports/bifrost-http/plugins/logging/utils.go:509-514
Timestamp: 2025-07-08T16:48:25.386Z
Learning: In the Bifrost logging system (transports/bifrost-http/plugins/logging/utils.go), the Content field in message structures is a struct value type, not a pointer, so it will never be nil and doesn't require nil checks. However, ContentStr within Content is a pointer and should be checked for nil.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/logging/main.gocore/schemas/bifrost.go
📚 Learning: in the bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), pratham-mishra04 p...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#152
File: transports/bifrost-http/plugins/logging/utils.go:16-18
Timestamp: 2025-07-10T13:44:39.237Z
Learning: In the Bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), Pratham-Mishra04 prefers to ignore JSON marshaling errors when storing log entries because logging is not critical for their use case and they are certain the marshaling operations won't fail.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/logging/main.gocore/schemas/bifrost.go
📚 Learning: in the bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), pratham-mishra04 p...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#152
File: transports/bifrost-http/plugins/logging/utils.go:378-399
Timestamp: 2025-07-10T13:44:14.518Z
Learning: In the Bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go), Pratham-Mishra04 prefers not to add error handling for JSON unmarshaling operations, considering logging not very critical and being confident that JSON marshalling won't fail in practice.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/logging/main.gocore/schemas/bifrost.go
📚 Learning: in the bifrost project, breaking api changes are acceptable when features are not yet public. this a...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#144
File: transports/bifrost-http/handlers/providers.go:45-49
Timestamp: 2025-07-08T16:50:27.699Z
Learning: In the Bifrost project, breaking API changes are acceptable when features are not yet public. This applies to scenarios like changing struct fields from pointer to non-pointer types in request/response structures for unreleased features.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/integrations/openai/types.gocore/schemas/bifrost.go
📚 Learning: pratham-mishra04 prefers not to add error handling for json marshaling operations in the bifrost log...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#152
File: transports/bifrost-http/plugins/logging/utils.go:94-111
Timestamp: 2025-07-10T13:44:23.297Z
Learning: Pratham-Mishra04 prefers not to add error handling for JSON marshaling operations in the Bifrost logging plugin (transports/bifrost-http/plugins/logging/utils.go) because logging is not critical functionality and the structured schema data being marshaled is unlikely to fail. They accept the risk of not handling json.Marshal errors in logging contexts to keep the code simple.
Applied to files:
transports/bifrost-http/plugins/logging/models.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/main.gocore/schemas/bifrost.go
📚 Learning: in core/providers/anthropic.go, the content field in formattedmessages is always of type []interface...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:526-550
Timestamp: 2025-06-04T09:29:46.287Z
Learning: In core/providers/anthropic.go, the content field in formattedMessages is always of type []interface{} because it's explicitly constructed that way upstream in the prepareAnthropicChatRequest function. Defensive type casting for multiple types is not needed since the type is guaranteed by the construction logic.
Applied to files:
transports/bifrost-http/plugins/logging/models.gocore/providers/mistral.gocore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: the bifrost codebase uses string alias types (like `type contextkey string`) for context keys consis...
Learnt from: connyay
PR: maximhq/bifrost#92
File: core/providers/utils.go:60-64
Timestamp: 2025-06-17T14:04:21.104Z
Learning: The bifrost codebase uses string alias types (like `type ContextKey string`) for context keys consistently across multiple packages including plugins/maxim/main.go and transports/bifrost-http/tracking/plugin.go. This pattern should be maintained for consistency rather than switching to the canonical struct{} approach.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/telemetry/main.gotransports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/integrations/openai/types.gocore/providers/cohere.go
📚 Learning: in the bifrost schema (core/schemas/bifrost.go), only usermessage and toolmessage structs have image...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#64
File: transports/bifrost-http/integrations/genai/types.go:383-395
Timestamp: 2025-06-09T16:26:05.777Z
Learning: In the Bifrost schema (core/schemas/bifrost.go), only UserMessage and ToolMessage structs have ImageContent fields. AssistantMessage does not have an ImageContent field and cannot contain images. The schema design intentionally limits image content to user and tool messages only.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/logging/main.gocore/providers/bedrock.gocore/providers/cohere.go
📚 Learning: in core/schemas/bifrost.go, the toolchoice unmarshaljson validation intentionally only checks for em...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/schemas/bifrost.go:186-190
Timestamp: 2025-06-15T14:18:32.703Z
Learning: In core/schemas/bifrost.go, the ToolChoice UnmarshalJSON validation intentionally only checks for empty Type fields and lets providers handle validation of specific tool choice values. This architectural decision keeps schema validation focused on structure while allowing provider-specific semantic validation.
Applied to files:
transports/bifrost-http/plugins/logging/models.gocore/providers/mistral.gotransports/bifrost-http/plugins/logging/main.gocore/providers/openai.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: the openai `name` field on messages cannot be preserved when converting to bifrost format because th...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:223-231
Timestamp: 2025-06-10T11:06:06.670Z
Learning: The OpenAI `name` field on messages cannot be preserved when converting to Bifrost format because the `schemas.BifrostMessage` struct in bifrost/core does not support a Name field. This is a known limitation of the Bifrost core schema design.
Applied to files:
transports/bifrost-http/plugins/logging/models.gocore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in core/providers/bedrock.go, for tool call result messages (modelchatmessageroletool), the content ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/bedrock.go:443-468
Timestamp: 2025-06-04T09:32:15.826Z
Learning: In core/providers/bedrock.go, for tool call result messages (ModelChatMessageRoleTool), the Content field represents the actual tool call output. A tool result message should only be created when msg.Content is non-nil, as there's no semantic meaning to a tool result without output content.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/logging/main.gocore/providers/bedrock.gocore/providers/cohere.go
📚 Learning: in the bifrosterror struct, the error field is a struct (not a pointer), so accessing bifrosterr.err...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#80
File: plugins/maxim/main.go:249-264
Timestamp: 2025-06-14T06:17:54.426Z
Learning: In the BifrostError struct, the Error field is a struct (not a pointer), so accessing bifrostErr.Error.Message, bifrostErr.Error.Code, and bifrostErr.Error.Type is safe without nil checks on the Error field itself. The Code and Type fields are of type *string.
Applied to files:
transports/bifrost-http/plugins/logging/models.gotransports/bifrost-http/plugins/logging/main.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in the bifrost project, bifrostconfig struct is never marshaled/unmarshaled, so serialization tags (...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#94
File: core/schemas/bifrost.go:20-23
Timestamp: 2025-06-18T15:16:23.127Z
Learning: In the Bifrost project, BifrostConfig struct is never marshaled/unmarshaled, so serialization tags (json, yaml) are not needed for its fields.
Applied to files:
transports/bifrost-http/plugins/logging/models.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in the json parser plugin (plugins/jsonparser/main.go), the posthook method is designed with a contr...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#209
File: plugins/jsonparser/plugin_test.go:38-45
Timestamp: 2025-08-04T19:39:39.417Z
Learning: In the JSON Parser plugin (plugins/jsonparser/main.go), the PostHook method is designed with a contract that guarantees the response structure (Choices, BifrostStreamResponseChoice, Delta, Content) will always be present when called, making defensive nil checks unnecessary in tests.
Applied to files:
transports/bifrost-http/plugins/telemetry/main.gocore/schemas/bifrost.go
📚 Learning: in core/bifrost.go, the count parameter in runposthooks method is intentionally kept separate from p...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#79
File: core/bifrost.go:94-103
Timestamp: 2025-06-14T04:06:58.240Z
Learning: In core/bifrost.go, the count parameter in RunPostHooks method is intentionally kept separate from p.executedPreHooks to support circuit breaker plugins that may need to trigger PostHooks for only a subset of executed plugins when detecting failure conditions mid-execution.
Applied to files:
transports/bifrost-http/plugins/telemetry/main.go
📚 Learning: in the bifrost provider architecture, `handleproviderresponse` is a utility function that only parse...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#196
File: core/providers/openai.go:180-183
Timestamp: 2025-07-29T16:10:52.088Z
Learning: In the Bifrost provider architecture, `handleProviderResponse` is a utility function that only parses and returns raw response data when the `sendBackRawResponse` flag is true. It's the responsibility of each individual provider (OpenAI, Anthropic, etc.) to conditionally set `response.ExtraFields.RawResponse` using the returned raw response data based on their `sendBackRawResponse` flag. This represents a separation of concerns where the utility handles parsing and the provider handles response object construction.
Applied to files:
core/providers/mistral.gocore/providers/openai.gocore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.go
📚 Learning: in the bifrost project, the fallback format has been updated from object structure {"provider": "......
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#169
File: docs/usage/http-transport/openapi.json:1352-1358
Timestamp: 2025-07-17T08:56:59.907Z
Learning: In the Bifrost project, the fallback format has been updated from object structure {"provider": "...", "model": "..."} to a simpler string format "provider/model" (e.g., "anthropic/claude-3-sonnet-20240229"). The current OpenAPI schema correctly reflects this new format.
Applied to files:
core/providers/mistral.goui/lib/types/logs.tscore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/bedrock.gocore/schemas/bifrost.go
📚 Learning: in transports/bifrost-http/integrations/genai/types.go, when systeminstruction has an empty role, th...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#89
File: transports/bifrost-http/integrations/genai/types.go:151-155
Timestamp: 2025-06-16T14:45:48.563Z
Learning: In transports/bifrost-http/integrations/genai/types.go, when SystemInstruction has an empty role, the user prefers to let the downstream provider (Google GenAI) handle validation and return errors, rather than implementing validation in the bifrost layer. This represents a design preference for delegating validation to the appropriate service rather than duplicating validation logic in the proxy layer.
Applied to files:
core/providers/mistral.gocore/providers/openai.gocore/providers/bedrock.gocore/providers/cohere.go
📚 Learning: in the bifrost codebase, performance is prioritized over defensive copying for http service operatio...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/mistral.go:168-170
Timestamp: 2025-06-15T14:24:49.882Z
Learning: In the Bifrost codebase, performance is prioritized over defensive copying for HTTP service operations. Specifically, shallow slice assignments in provider response handling are acceptable due to object pool reset patterns and JSON unmarshaling behavior that minimize practical data corruption risks.
Applied to files:
core/providers/mistral.gotransports/go.modcore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: when json unmarshaling into pooled structs, slice fields like `choices []schemas.bifrostresponsechoi...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#88
File: core/providers/mistral.go:170-176
Timestamp: 2025-06-16T06:56:55.290Z
Learning: When JSON unmarshaling into pooled structs, slice fields like `Choices []schemas.BifrostResponseChoice` get fresh heap memory allocations from `json.Unmarshal()`. The slice data is not part of the pooled struct's memory, so defensive copying is unnecessary. Resetting pooled structs with `*resp = ResponseType{}` only clears slice headers, not the underlying data.
Applied to files:
core/providers/mistral.gocore/providers/openai.gocore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: for the anthropic provider in core/providers/anthropic.go, it's acceptable to pass potentially malfo...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/providers/anthropic.go:0-0
Timestamp: 2025-06-04T05:44:09.141Z
Learning: For the Anthropic provider in core/providers/anthropic.go, it's acceptable to pass potentially malformed messages with invalid roles because Anthropic's API will return suitable error responses for role issues, eliminating the need for additional validation logging.
Applied to files:
core/providers/mistral.gocore/providers/bedrock.gocore/providers/cohere.go
📚 Learning: the chatcompletionrequest method in the bifrost client follows a contract where the result parameter...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/utils.go:169-173
Timestamp: 2025-06-09T17:33:52.234Z
Learning: The ChatCompletionRequest method in the Bifrost client follows a contract where the result parameter will never be nil if the error parameter is nil. This means when error checking passes (err == nil), the result is guaranteed to be valid and can be safely used without additional nil checks.
Applied to files:
core/providers/mistral.gocore/providers/openai.gocore/providers/azure.go
📚 Learning: in transports/bifrost-http/handlers/completions.go, for speech completion requests, the user prefers...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#177
File: transports/bifrost-http/handlers/completions.go:248-264
Timestamp: 2025-07-22T12:14:08.826Z
Learning: In transports/bifrost-http/handlers/completions.go, for speech completion requests, the user prefers to let the provider handle ResponseFormat validation rather than validating supported audio formats ("mp3", "opus", "aac", "flac") at the HTTP transport layer. This follows the architectural pattern of delegating domain-specific validation to providers rather than duplicating validation logic in the transport layer.
Applied to files:
core/providers/mistral.gocore/providers/openai.gocore/providers/azure.gocore/schemas/bifrost.go
📚 Learning: in the bifrost codebase, errors returned from client methods like chatcompletionrequest are of type ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/end_to_end_tool_calling.go:43-45
Timestamp: 2025-06-16T04:13:55.437Z
Learning: In the Bifrost codebase, errors returned from client methods like ChatCompletionRequest are of type BifrostError, not the standard error interface. For testing these errors, use require.Nilf instead of require.NoErrorf since BifrostError doesn't work with the standard error assertion methods.
Applied to files:
core/providers/mistral.gotransports/go.modcore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in the bifrost codebase, errors returned from methods like chatcompletionrequest are of type bifrost...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/simple_chat.go:39-41
Timestamp: 2025-06-16T04:13:42.755Z
Learning: In the Bifrost codebase, errors returned from methods like ChatCompletionRequest are of type BifrostError (a custom error type) rather than the standard Go error interface. Therefore, require.Nilf should be used for error assertions instead of require.NoErrorf.
Applied to files:
core/providers/mistral.gotransports/go.modcore/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in the bifrost repository's transport dependency update workflow, when updating the core dependency ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#103
File: .github/workflows/transport-dependency-update.yml:53-75
Timestamp: 2025-06-20T16:21:18.912Z
Learning: In the bifrost repository's transport dependency update workflow, when updating the core dependency to a new version using `go get`, the go.mod and go.sum files will always change in normal operation, making the safety check for changes more of a defensive programming practice rather than handling a common scenario.
Applied to files:
transports/go.modtransports/bifrost-http/plugins/logging/main.go
📚 Learning: the `core-providers-test` module in `tests/core-providers/` is an internal testing module that will ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/go.mod:38-38
Timestamp: 2025-06-16T03:54:48.005Z
Learning: The `core-providers-test` module in `tests/core-providers/` is an internal testing module that will never be consumed as a dependency by external projects, so the replace directive pointing to `../../core` is acceptable for local development and testing purposes.
Applied to files:
transports/go.mod
📚 Learning: in go, when importing a package, the identifier used to access it is determined by the `package` dec...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#135
File: docs/core-package.md:105-116
Timestamp: 2025-06-27T17:07:39.462Z
Learning: In Go, when importing a package, the identifier used to access it is determined by the `package` declaration in the Go source files, not the directory name. For the Bifrost project, the core directory files declare `package bifrost`, so importing `"github.com/maximhq/bifrost/core"` automatically makes it accessible as `bifrost.Init`, `bifrost.Ptr`, etc., without needing an explicit alias.
Applied to files:
transports/go.mod
📚 Learning: in the bifrost project, the tests directory structure has `tests/core-providers/` and `tests/transpo...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#149
File: docs/contributing/README.md:22-27
Timestamp: 2025-07-08T18:12:13.590Z
Learning: In the Bifrost project, the tests directory structure has `tests/core-providers/` and `tests/transports-integrations/` as sibling directories. From `tests/core-providers/`, the correct relative path to reach `tests/transports-integrations/` is `../transports-integrations/`, not `../../tests/transports-integrations/`.
Applied to files:
transports/go.mod
📚 Learning: in go module files, `go 1.24.1` (with patch version) can work fine in some setups, contrary to the g...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/go.mod:3-4
Timestamp: 2025-06-16T04:27:53.538Z
Learning: In Go module files, `go 1.24.1` (with patch version) can work fine in some setups, contrary to the general rule that go directives should only include major.minor versions.
Applied to files:
transports/go.mod
📚 Learning: in the bifrost system, error returns are of type `bifrosterror` rather than the standard go `error` ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/complete_end_to_end.go:39-41
Timestamp: 2025-06-16T04:12:05.427Z
Learning: In the Bifrost system, error returns are of type `BifrostError` rather than the standard Go `error` interface. Therefore, use `require.Nilf(t, err, ...)` instead of `require.NoError(t, err)` when checking for errors in Bifrost function calls.
Applied to files:
transports/go.mod
📚 Learning: in the bifrost project, the user prefers to use `package main` for test files in the tests/core-prov...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/openai_test.go:1-2
Timestamp: 2025-06-16T04:29:53.409Z
Learning: In the Bifrost project, the user prefers to use `package main` for test files in the tests/core-providers directory rather than more descriptive package names like `coreproviders_test`.
Applied to files:
transports/go.mod
📚 Learning: in the bifrost test suite (tests/core-providers), parallel tests using t.parallel() are not being im...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/scenarios/automatic_function_calling.go:22-22
Timestamp: 2025-06-16T04:55:11.886Z
Learning: In the Bifrost test suite (tests/core-providers), parallel tests using t.Parallel() are not being implemented currently. The team plans to add parallel test execution in future enhancements.
Applied to files:
transports/go.mod
📚 Learning: in the google genai integration at transports/bifrost-http/integrations/genai/types.go, the manual u...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#89
File: transports/bifrost-http/integrations/genai/types.go:22-56
Timestamp: 2025-06-16T14:50:46.859Z
Learning: In the Google GenAI integration at transports/bifrost-http/integrations/genai/types.go, the manual URL-safe base64 decoding implementation (converting - to +, _ to /, and adding padding) is required because base64.RawURLEncoding.DecodeString fails for the specific url encoded bytes format being handled.
Applied to files:
transports/go.modcore/providers/openai.gotransports/bifrost-http/integrations/openai/types.go
📚 Learning: github.com/stretchr/testify v1.10.0 was released on november 23, 2024 and is the latest stable versi...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#55
File: core/go.mod:30-36
Timestamp: 2025-06-04T04:52:31.748Z
Learning: github.com/stretchr/testify v1.10.0 was released on November 23, 2024 and is the latest stable version as of 2024-2025. It includes security fixes for CVE-2022-28948 in gopkg.in/yaml.v3 dependency.
Applied to files:
transports/go.mod
📚 Learning: go 1.24 was released in february 2025 and is stable and available for use in go.mod files....
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#81
File: tests/core-providers/go.mod:3-4
Timestamp: 2025-06-16T03:55:16.949Z
Learning: Go 1.24 was released in February 2025 and is stable and available for use in go.mod files.
Applied to files:
transports/go.mod
📚 Learning: in the bifrost openai integration (transports/bifrost-http/integrations/openai/types.go), the conver...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#63
File: transports/bifrost-http/integrations/openai/types.go:89-119
Timestamp: 2025-06-10T11:00:02.875Z
Learning: In the Bifrost OpenAI integration (transports/bifrost-http/integrations/openai/types.go), the convertOpenAIContent function currently only handles the last image URL when multiple images are present in a content array. The user Pratham-Mishra04 has acknowledged this limitation and indicated it's part of a larger architectural issue that will be addressed comprehensively later, rather than with piecemeal fixes.
Applied to files:
core/providers/openai.gotransports/bifrost-http/integrations/openai/types.gocore/schemas/bifrost.go
📚 Learning: in transports/bifrost-http/integrations/genai/types.go, when systeminstruction has an empty role, th...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#89
File: transports/bifrost-http/integrations/genai/types.go:151-155
Timestamp: 2025-06-16T14:44:42.893Z
Learning: In transports/bifrost-http/integrations/genai/types.go, when SystemInstruction has an empty role, the user prefers to return a validation error rather than setting a default role value. This represents a design preference for strict input validation over silent error correction.
Applied to files:
core/providers/openai.go
📚 Learning: go 1.23 introduced the ability to range over integers. the syntax `for range n` where n is an intege...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: core/providers/ollama.go:68-72
Timestamp: 2025-06-15T14:31:59.649Z
Learning: Go 1.23 introduced the ability to range over integers. The syntax `for range n` where n is an integer will iterate from 0 to n-1, making `for range config.ConcurrencyAndBufferSize.Concurrency` valid syntax for iterating a specific number of times without needing an explicit counter variable.
Applied to files:
core/providers/azure.go
📚 Learning: go 1.22 introduced the ability to range over integers. the syntax `for range n` where n is an intege...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: core/providers/ollama.go:68-72
Timestamp: 2025-06-15T14:31:59.649Z
Learning: Go 1.22 introduced the ability to range over integers. The syntax `for range n` where n is an integer will iterate from 0 to n-1, making `for range config.ConcurrencyAndBufferSize.Concurrency` valid syntax for iterating a specific number of times without needing an explicit counter variable. This feature requires Go module version 1.22 or later.
Applied to files:
core/providers/azure.go
📚 Learning: in the genericrouter (transports/bifrost-http/integrations), responsefunc is not called if the bifro...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/router.go:19-33
Timestamp: 2025-06-09T16:46:32.018Z
Learning: In the GenericRouter (transports/bifrost-http/integrations), ResponseFunc is not called if the BifrostResponse parameter is nil, providing built-in protection against nil response marshaling.
Applied to files:
core/providers/azure.gocore/providers/bedrock.gocore/providers/cohere.gocore/schemas/bifrost.go
📚 Learning: in anthropic api integration for bifrost, messages won't contain both image and tool_result content ...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#65
File: transports/bifrost-http/integrations/anthropic/types.go:131-180
Timestamp: 2025-06-10T13:11:37.867Z
Learning: In Anthropic API integration for Bifrost, messages won't contain both image and tool_result content blocks in the same message, so defensive guards against multiple embedded message structs are unnecessary in the content processing loop.
Applied to files:
core/providers/bedrock.gocore/schemas/bifrost.go
📚 Learning: in the bifrost codebase, when working with aws bedrock provider authentication, the preference is to...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/providers/bedrock.go:241-252
Timestamp: 2025-06-04T09:07:20.867Z
Learning: In the Bifrost codebase, when working with AWS Bedrock provider authentication, the preference is to let AWS handle access key validation naturally rather than adding preemptive checks for empty/blank access keys. This allows AWS to provide its own authentication error messages which can be more informative than custom validation errors.
Applied to files:
core/providers/bedrock.go
📚 Learning: for cohere v1 api in core/providers/cohere.go, the tool_choice parameter formatting uses uppercase s...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/cohere.go:327-335
Timestamp: 2025-06-15T13:46:24.869Z
Learning: For Cohere v1 API in core/providers/cohere.go, the tool_choice parameter formatting uses uppercase strings for the "type" field (e.g., "AUTO", "TOOL") and follows a different structure than initially assumed. The current implementation with strings.ToUpper() for the type field is correct for the v1 API.
Applied to files:
core/providers/cohere.go
📚 Learning: cohere v1 api tool_choice parameter accepts only uppercase string values: "required" and "none". unl...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#83
File: core/providers/cohere.go:327-335
Timestamp: 2025-06-15T13:46:24.869Z
Learning: Cohere v1 API tool_choice parameter accepts only uppercase string values: "REQUIRED" and "NONE". Unlike other providers, it doesn't use structured objects with "type" and "name" fields. The current implementation in core/providers/cohere.go correctly uses strings.ToUpper() to convert ToolChoiceStruct.Type to uppercase format as expected by the API.
Applied to files:
core/providers/cohere.go
📚 Learning: the `checkandsetdefaults()` method on `*schemas.providerconfig` in go does not return any error - it...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#84
File: core/providers/ollama.go:59-61
Timestamp: 2025-06-15T14:34:29.401Z
Learning: The `CheckAndSetDefaults()` method on `*schemas.ProviderConfig` in Go does not return any error - it has a void return type and only sets default values on the configuration struct.
Applied to files:
core/providers/cohere.go
📚 Learning: breaking changes in the bifrost codebase are managed by first merging and tagging core schema change...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#54
File: core/schemas/provider.go:148-148
Timestamp: 2025-06-04T03:57:50.981Z
Learning: Breaking changes in the Bifrost codebase are managed by first merging and tagging core schema changes, then updating dependent code references in subsequent steps after the core version is released.
Applied to files:
core/schemas/bifrost.go
📚 Learning: in the bifrost project, when users pass empty messages (no content blocks and no content string), th...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#75
File: transports/bifrost-http/integrations/genai/types.go:161-178
Timestamp: 2025-06-14T08:45:19.119Z
Learning: In the Bifrost project, when users pass empty messages (no content blocks and no content string), the system should error rather than trying to handle them gracefully. This is an intentional design decision - empty messages that would result in invalid JSON serialization are expected to cause errors to fail fast on invalid user input.
Applied to files:
core/schemas/bifrost.go
📚 Learning: in the bifrost project's mcp configuration handling, empty environment variables should be treated a...
Learnt from: Pratham-Mishra04
PR: maximhq/bifrost#131
File: transports/bifrost-http/lib/config.go:35-68
Timestamp: 2025-06-26T07:37:24.385Z
Learning: In the Bifrost project's MCP configuration handling, empty environment variables should be treated as missing/invalid rather than as valid empty values. The current implementation using `os.Getenv(envKey); envValue != ""` to check for non-empty values is the desired behavior.
Applied to files:
core/schemas/bifrost.go
🧬 Code Graph Analysis (8)
transports/bifrost-http/plugins/logging/models.go (2)
core/schemas/bifrost.go (1)
BifrostEmbedding(493-497)ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
transports/bifrost-http/plugins/telemetry/main.go (2)
ui/components/ui/input.tsx (1)
Input(7-22)core/schemas/bifrost.go (1)
EmbeddingInput(66-68)
transports/bifrost-http/plugins/logging/main.go (2)
core/schemas/bifrost.go (1)
BifrostEmbedding(493-497)ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
ui/lib/types/logs.ts (1)
core/schemas/bifrost.go (1)
BifrostEmbedding(493-497)
transports/bifrost-http/integrations/openai/types.go (3)
core/schemas/bifrost.go (2)
BifrostEmbedding(493-497)LLMUsage(390-396)ui/lib/types/logs.ts (2)
BifrostEmbedding(110-114)LLMUsage(176-182)plugins/mocker/main.go (1)
Usage(138-142)
core/providers/bedrock.go (2)
core/schemas/bifrost.go (2)
BifrostEmbedding(493-497)BifrostEmbeddingResponse(499-503)ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
core/providers/cohere.go (2)
core/schemas/bifrost.go (2)
BifrostEmbedding(493-497)BifrostEmbeddingResponse(499-503)ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
core/schemas/bifrost.go (1)
ui/lib/types/logs.ts (1)
BifrostEmbedding(110-114)
🔇 Additional comments (21)
ui/components/logs/log-detail-sheet.tsx (1)
242-246: LGTM! UI properly adapted to new embedding structure.The change correctly extracts only the embedding vectors from the new
BifrostEmbeddingobjects for display, maintaining a clean user experience while accommodating the structured embedding format.transports/go.mod (1)
19-19: LGTM! Standard local development practice.The replace directive correctly points to the local core module, which is appropriate for testing the embedding response format changes before publishing the core updates.
transports/bifrost-http/plugins/telemetry/main.go (1)
62-63: LGTM! Consistent with existing telemetry pattern.The addition of embedding input detection follows the established pattern for method tagging in telemetry, ensuring proper categorization of embedding requests in metrics.
transports/bifrost-http/plugins/logging/models.go (1)
48-48: LGTM! Type change aligns with embedding standardization.The change from raw float32 slices to structured
BifrostEmbeddingobjects is consistent with the PR's goal of standardizing embedding response formats. The existing JSON serialization/deserialization logic will handle the new structured type correctly.ui/lib/types/logs.ts (2)
110-114: LGTM! TypeScript interface correctly mirrors Go schema.The
BifrostEmbeddinginterface properly reflects the Go struct definition with flexible embedding format support (string, 1D array, or 2D array).
226-226: LGTM! Type updated to match new embedding structure.The change from
number[][]toBifrostEmbedding[]is consistent with the backend type changes and provides richer embedding metadata in the UI.transports/bifrost-http/plugins/logging/main.go (2)
44-44: LGTM! Embedding output type updated to support standardized format.The change from
*[][]float32to*[]schemas.BifrostEmbeddingaligns with the PR's objective to standardize embedding response format across providers. This provides better structure and metadata for embedding data.
519-521: LGTM! Field access updated to match new schema structure.The change from
result.Embeddingtoresult.Datacorrectly reflects the schema update where theBifrostResponsestruct's embedding field was renamed and restructured to use the newBifrostEmbeddingformat.core/providers/mistral.go (1)
239-262: LGTM! Embedding method refactored to use unified response handling.The refactor successfully removes provider-specific response parsing logic and adopts the centralized
handleProviderResponsefunction. This eliminates code duplication and ensures consistent embedding response formatting across all providers, aligning with the PR's standardization objective.Key improvements:
- Uses pooled
schemas.BifrostResponsefor better memory management- Delegates embedding extraction to centralized handler
- Maintains provider metadata and raw response handling
- Follows the same pattern as other providers (Azure, OpenAI, Cohere, Bedrock)
core/providers/cohere.go (1)
682-693: LGTM! Embedding response structure updated to standardized format.The embedding response construction has been correctly updated to use the new
BifrostEmbeddingstructure. The implementation properly populates all required fields:
Object: "list"for the response containerDataslice with structured embedding objects- Each embedding includes
Index: 0,Object: "embedding", and the embedding dataThis addresses the previous review comment about missing required fields and aligns with the PR's standardization objective.
transports/bifrost-http/integrations/openai/types.go (2)
98-105: LGTM! Struct properly uses the standardized embedding type.The change to use
[]schemas.BifrostEmbeddingaligns perfectly with the PR's goal of standardizing embedding response format across providers.
429-442: Excellent simplification of the conversion logic!The function is now much cleaner by directly using
bifrostResp.Datainstead of manually constructing embedding objects. The nil check correctly references the newDatafield.core/providers/openai.go (1)
297-320: Well-structured refactoring using the centralized response handling pattern!The simplified implementation properly:
- Uses the response pool pattern with acquire/release
- Delegates parsing to the shared
handleProviderResponsefunction- Sets provider metadata appropriately
- Maintains backward compatibility with the
sendBackRawResponseflagThis aligns perfectly with the standardization effort across all providers.
core/providers/bedrock.go (2)
1166-1175: LGTM! Embedding response structure properly standardized.The changes correctly implement the new unified embedding response format with the
Datafield containingBifrostEmbeddingstructs. The Titan embedding is appropriately wrapped as a 2D array for consistency with the batch embedding format.
1225-1234: LGTM! Cohere embedding response correctly standardized.The implementation properly uses the new
BifrostEmbeddingstructure and correctly assigns the already 2DcohereResp.Embeddingsarray to theEmbedding2DArrayfield.core/providers/azure.go (3)
310-331: LGTM! ChatCompletion correctly uses the standardized response format.The method properly acquires a pooled
BifrostResponse, useshandleProviderResponsefor parsing, and correctly sets the provider and parameter metadata before returning.
361-381: LGTM! Embedding method properly implements the unified response handling.The refactored implementation correctly uses the pooled
BifrostResponse, delegates parsing tohandleProviderResponse, and properly sets all extra fields. This aligns perfectly with the standardization objectives.
54-72: LGTM! Chat response pool management correctly updated.The pool and its associated acquire/release functions have been properly updated to use
schemas.BifrostResponse, aligning with the standardized response format.core/schemas/bifrost.go (3)
376-378: LGTM! Field additions align well with the standardization goal.The explicit listing of object types in the comment and the new
Datafield for embeddings follow the standard OpenAI response format, which improves consistency across providers.
493-497: Structure correctly matches the TypeScript interface.The
BifrostEmbeddingstruct properly encapsulates embedding metadata (index, object type) along with the flexible embedding data, maintaining consistency with the frontend types defined inui/lib/types/logs.ts.
499-503: Well-designed union type for flexible embedding formats.The use of pointer fields follows the established pattern in the codebase for union types, allowing clear representation of different embedding formats (string/base64, 1D array, or 2D array).
78284a9 to
b3a79df
Compare
b3a79df to
e837714
Compare
# Unified Embedding Response Format This PR standardizes the embedding response format across all providers by introducing a new `BifrostEmbedding` type. The changes: 1. Replace provider-specific embedding response types with a unified `BifrostResponse` structure 2. Add a new `Data` field to `BifrostResponse` containing embedding results 3. Create a flexible `BifrostEmbeddingResponse` type that can handle different embedding formats (string, float32 array, 2D float32 array) 4. Update all providers (Azure, OpenAI, Mistral, Bedrock, Cohere) to use the new format 5. Modify UI components and logging to work with the new embedding structure This standardization simplifies the codebase by removing duplicate response handling logic across providers and creates a consistent interface for embedding results regardless of the underlying provider implementation.

Unified Embedding Response Format
This PR standardizes the embedding response format across all providers by introducing a new
BifrostEmbeddingtype. The changes:BifrostResponsestructureDatafield toBifrostResponsecontaining embedding resultsBifrostEmbeddingResponsetype that can handle different embedding formats (string, float32 array, 2D float32 array)This standardization simplifies the codebase by removing duplicate response handling logic across providers and creates a consistent interface for embedding results regardless of the underlying provider implementation.