refactor: log params and channel params

[xyfacai]

Summary by CodeRabbit

• New Features

  • Introduced structured channel settings with options for forced formatting, thinking-to-content conversion, and proxy configuration.
  • Added validation for channel settings during channel creation and update.
  • Provided utility functions for generic context value retrieval and JSON string conversion.

• Refactor

  • Replaced map-based channel settings with a strongly typed structure for improved clarity and reliability.
  • Standardized logging of consumption records by switching to structured parameter passing.
  • Simplified proxy and settings handling across multiple features for consistency.

• Bug Fixes

  • Enhanced error handling and validation for channel settings to prevent misconfiguration.

[coderabbitai]

Walkthrough

This update introduces a strongly typed struct ChannelSettings for channel configuration, replacing previous unstructured map usage throughout the codebase. Channel setting validation is added, and methods for getting and setting channel settings are refactored to use the new struct. Logging functions are also refactored to accept a parameter struct instead of multiple arguments. Several internal calls and context handling mechanisms are updated to use these new types and helpers.

Changes

File(s) / Area	Change Summary
common/gin.go	Added generic function GetContextKeyType[T any] for typed Gin context retrieval.
common/str.go	Added GetJsonString(data any) string utility for marshaling any data to JSON string.
controller/channel-test.go	Refactored RecordConsumeLog call to use a parameter struct instead of positional arguments.
controller/channel.go	Added channel settings validation using ValidateSettings() in add/update handlers.
dto/channel_settings.go	Introduced new ChannelSettings struct with ForceFormat, ThinkingToContent, and Proxy fields.
main.go	Moved logger setup into InitResources() after environment initialization.
middleware/distributor.go	Standardized Gin context key setting via common.SetContextKey.
model/channel.go	Added ValidateSettings(); refactored GetSetting() and SetSetting() to use ChannelSettings struct.
model/log.go	Introduced RecordConsumeLogParams struct; refactored RecordConsumeLog to use it.
relay/channel/api_request.go, .../coze/relay-coze.go, .../vertex/service_account.go	Changed proxy config access from map lookup to ChannelSettings.Proxy field.
relay/channel/openai/adaptor.go, .../openai/relay-openai.go	Changed channel setting access from map lookup/type assertion to direct struct field access.
relay/common/relay_info.go	Changed RelayInfo.ChannelSetting type to ChannelSettings; updated context retrieval accordingly.
relay/relay-mj.go, relay/relay-text.go, relay/relay_task.go, service/quota.go	Refactored all RecordConsumeLog calls to use the parameter struct.

Sequence Diagram(s)

sequenceDiagram
    participant Controller
    participant Model
    participant DTO
    participant GinContext
    participant Middleware

    Controller->Model: AddChannel/UpdateChannel(channel)
    Model->DTO: ValidateSettings()
    DTO-->>Model: ChannelSettings struct
    Model->GinContext: SetContextKey(ChannelSetting, ChannelSettings)
    Middleware->GinContext: SetContextKey(constant.ChannelSetting, ChannelSettings)
    Controller->Model: RecordConsumeLog(userId, RecordConsumeLogParams)
    Model->Model: LogQuotaData(params)

Loading

Possibly related PRs

• ✨ feat: refactor environment variable initialization #1326: Adds a suite of typed context key helper functions in common/gin.go, closely related to the new generic typed getter introduced here.

Poem

In fields of code, a rabbit hops,
With structs and types, it never stops.
Channel settings now are neat,
Logging params, concise and sweet.
Context keys, so typed and spry—
This bunny’s code will never die!
🐇

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 265c7d9 and 751aea5.

📒 Files selected for processing (19)

• common/gin.go (1 hunks)
• common/str.go (1 hunks)
• controller/channel-test.go (1 hunks)
• controller/channel.go (2 hunks)
• dto/channel_settings.go (1 hunks)
• main.go (1 hunks)
• middleware/distributor.go (2 hunks)
• model/channel.go (3 hunks)
• model/log.go (3 hunks)
• relay/channel/api_request.go (1 hunks)
• relay/channel/coze/relay-coze.go (1 hunks)
• relay/channel/openai/adaptor.go (1 hunks)
• relay/channel/openai/relay-openai.go (2 hunks)
• relay/channel/vertex/service_account.go (1 hunks)
• relay/common/relay_info.go (3 hunks)
• relay/relay-mj.go (5 hunks)
• relay/relay-text.go (1 hunks)
• relay/relay_task.go (1 hunks)
• service/quota.go (3 hunks)

🧰 Additional context used

🧠 Learnings (7)

relay/channel/openai/adaptor.go (1)

Learnt from: 9Ninety
PR: QuantumNous/new-api#1273
File: relay/channel/gemini/relay-gemini.go:97-116
Timestamp: 2025-06-21T03:37:41.726Z
Learning: In relay/channel/gemini/relay-gemini.go, the thinking budget calculation logic (including the MaxOutputTokens multiplication) was introduced in PR #1247. PR #1273 focused specifically on decoupling the thoughts summary feature from thinking budget settings and did not modify the existing thinking budget behavior.

relay/relay-text.go (1)

Learnt from: 9Ninety
PR: QuantumNous/new-api#1273
File: relay/channel/gemini/relay-gemini.go:97-116
Timestamp: 2025-06-21T03:37:41.726Z
Learning: In relay/channel/gemini/relay-gemini.go, the thinking budget calculation logic (including the MaxOutputTokens multiplication) was introduced in PR #1247. PR #1273 focused specifically on decoupling the thoughts summary feature from thinking budget settings and did not modify the existing thinking budget behavior.

common/gin.go (2)

Learnt from: feitianbubu
PR: QuantumNous/new-api#1228
File: router/main.go:28-36
Timestamp: 2025-06-15T12:38:11.806Z
Learning: gin.Context implements context.Context interface since Gin v1.8.0, providing the methods Deadline(), Done(), Err(), and Value(). When using Gin v1.8.0 or later, gin.Context can be passed directly to functions expecting context.Context without needing to extract c.Request.Context().

Learnt from: feitianbubu
PR: QuantumNous/new-api#1228
File: router/main.go:28-36
Timestamp: 2025-06-15T12:38:11.806Z
Learning: gin.Context implements context.Context interface since Gin v1.8.0, providing the methods Deadline(), Done(), Err(), and Value(). When using Gin v1.8.0 or later, gin.Context can be passed directly to functions expecting context.Context without needing to extract c.Request.Context().

middleware/distributor.go (2)

Learnt from: feitianbubu
PR: QuantumNous/new-api#1228
File: router/main.go:28-36
Timestamp: 2025-06-15T12:38:11.806Z
Learning: gin.Context implements context.Context interface since Gin v1.8.0, providing the methods Deadline(), Done(), Err(), and Value(). When using Gin v1.8.0 or later, gin.Context can be passed directly to functions expecting context.Context without needing to extract c.Request.Context().

Learnt from: feitianbubu
PR: QuantumNous/new-api#1228
File: router/main.go:28-36
Timestamp: 2025-06-15T12:38:11.806Z
Learning: gin.Context implements context.Context interface since Gin v1.8.0, providing the methods Deadline(), Done(), Err(), and Value(). When using Gin v1.8.0 or later, gin.Context can be passed directly to functions expecting context.Context without needing to extract c.Request.Context().

relay/relay_task.go (1)

Learnt from: 9Ninety
PR: QuantumNous/new-api#1273
File: relay/channel/gemini/relay-gemini.go:97-116
Timestamp: 2025-06-21T03:37:41.726Z
Learning: In relay/channel/gemini/relay-gemini.go, the thinking budget calculation logic (including the MaxOutputTokens multiplication) was introduced in PR #1247. PR #1273 focused specifically on decoupling the thoughts summary feature from thinking budget settings and did not modify the existing thinking budget behavior.

service/quota.go (1)

Learnt from: neotf
PR: QuantumNous/new-api#1120
File: service/quota.go:0-0
Timestamp: 2025-06-18T12:20:25.779Z
Learning: For OpenRouter integration: cacheTokens returned from upstream always belong to [0, promptTokens], meaning cacheTokens will never exceed the original promptTokens value. This constraint ensures that operations like `promptTokens -= cacheTokens` will not result in negative values.

relay/relay-mj.go (1)

Learnt from: 9Ninety
PR: QuantumNous/new-api#1273
File: relay/channel/gemini/relay-gemini.go:97-116
Timestamp: 2025-06-21T03:37:41.726Z
Learning: In relay/channel/gemini/relay-gemini.go, the thinking budget calculation logic (including the MaxOutputTokens multiplication) was introduced in PR #1247. PR #1273 focused specifically on decoupling the thoughts summary feature from thinking budget settings and did not modify the existing thinking budget behavior.

🧬 Code Graph Analysis (14)

relay/channel/vertex/service_account.go (1)

service/http_client.go (1)

• NewProxyHttpClient (32-81)

relay/channel/api_request.go (1)

service/http_client.go (1)

• NewProxyHttpClient (32-81)

relay/relay-text.go (1)

model/log.go (2)

• RecordConsumeLog (155-204)
• RecordConsumeLogParams (139-153)

common/gin.go (1)

constant/context_key.go (1)

• ContextKey (3-3)

relay/channel/coze/relay-coze.go (1)

service/http_client.go (1)

• NewProxyHttpClient (32-81)

middleware/distributor.go (2)

common/gin.go (1)

• SetContextKey (48-50)

constant/context_key.go (3)

• ContextKeyChannelType (21-21)
• ContextKeyChannelSetting (23-23)
• ContextKeyBaseUrl (20-20)

dto/channel_settings.go (1)

constant/channel_setting.go (1)

• ForceFormat (4-4)

main.go (1)

common/logger.go (1)

• SetupLogger (29-48)

relay/relay_task.go (1)

model/log.go (2)

• RecordConsumeLog (155-204)
• RecordConsumeLogParams (139-153)

relay/common/relay_info.go (3)

dto/channel_settings.go (1)

• ChannelSettings (3-7)

common/gin.go (1)

• GetContextKeyType (80-88)

constant/context_key.go (1)

• ContextKeyChannelSetting (23-23)

controller/channel-test.go (1)

model/log.go (2)

• RecordConsumeLog (155-204)
• RecordConsumeLogParams (139-153)

relay/channel/openai/relay-openai.go (1)

constant/channel_setting.go (1)

• ForceFormat (4-4)

service/quota.go (1)

model/log.go (2)

• RecordConsumeLog (155-204)
• RecordConsumeLogParams (139-153)

model/log.go (5)

common/logger.go (1)

• LogInfo (60-62)

common/str.go (2)

• GetJsonString (77-83)
• MapToJsonStr (27-33)

common/constants.go (1)

• LogConsumeEnabled (73-73)

model/usedata.go (1)

• LogQuotaData (63-70)

common/utils.go (1)

• GetTimestamp (192-194)

🔇 Additional comments (32)

common/gin.go (1)

80-88: LGTM! Well-designed generic context getter.

This generic function provides type-safe context value retrieval using Go generics. The implementation correctly follows the two-step validation pattern (key existence + type assertion) and returns idiomatic Go values (zero value + false on failure).

common/str.go (1)

77-83: LGTM! Simple and effective JSON utility function.

The function handles nil input gracefully and provides a convenient way to convert any data to JSON string. The silent error handling is appropriate for a utility function of this nature.

main.go (1)

174-174: LGTM! Improved initialization order.

Moving logger setup to occur after environment variable loading is a logical improvement. This ensures that logger configuration can properly utilize environment variables (such as LogDir) that may affect its behavior.

relay/channel/vertex/service_account.go (1)

109-110: LGTM! Improved type safety with direct field access.

The change from map lookup with type assertion to direct field access on the typed ChannelSetting.Proxy field improves type safety and code clarity. This aligns well with the broader refactoring to use strongly typed structs for channel settings.

relay/channel/openai/adaptor.go (1)

56-56: LGTM! Enhanced type safety with direct boolean field access.

The change from map lookup with type assertion to direct field access on the typed ChannelSetting.ThinkingToContent boolean field improves type safety and makes the conditional check more readable. This is consistent with the broader refactoring to use strongly typed structs for channel settings.

relay/channel/api_request.go (1)

209-210: LGTM! Clean refactoring to typed struct access.

The transition from map-based access (info.ChannelSetting["proxy"]) to direct struct field access (info.ChannelSetting.Proxy) improves type safety while maintaining the same logical behavior. The service.NewProxyHttpClient() function properly handles empty proxy strings, so this change is safe.

controller/channel.go (2)

390-397: LGTM! Proper validation addition with appropriate error handling.

The validation is correctly placed after JSON binding and before database operations. The early return on validation failure prevents invalid settings from being persisted.

---

625-632: LGTM! Consistent validation implementation.

The validation follows the same pattern as in AddChannel, ensuring consistent behavior across both functions.

relay/channel/coze/relay-coze.go (1)

281-282: LGTM! Consistent refactoring aligned with the broader type safety improvements.

This change mirrors the refactoring in relay/channel/api_request.go, replacing map-based proxy access with direct struct field access. The logic remains functionally equivalent while improving type safety.

dto/channel_settings.go (1)

3-7: LGTM! Well-designed DTO with appropriate field types and JSON tags.

The struct provides a clean typed interface for channel settings. The use of omitempty for boolean fields is sensible, and the field names align with existing constants (e.g., ForceFormat matches constant/channel_setting.go). The Proxy field appropriately omits omitempty to ensure consistent serialization.

middleware/distributor.go (3)

250-250: LGTM! Improved type safety with standardized context key usage.

Using common.SetContextKey() with typed constants (constant.ContextKeyChannelType) instead of direct string-based c.Set() calls improves consistency and reduces the risk of typos in context key names.

---

252-252: LGTM! Consistent with the typed context key approach.

The use of constant.ContextKeyChannelSetting aligns with the broader refactoring to typed channel settings and standardized context key management.

---

261-261: LGTM! Completes the consistent context key standardization.

Using constant.ContextKeyBaseUrl maintains consistency with the other context key changes in this function.

relay/relay-text.go (1)

543-557: LGTM! Clean refactoring to structured parameters.

The refactoring from multiple positional parameters to a structured RecordConsumeLogParams approach significantly improves code readability and maintainability. All necessary fields are properly mapped from the original implementation.

relay/relay_task.go (1)

142-152: LGTM! Consistent with codebase refactoring pattern.

The structured parameter approach is properly implemented and consistent with similar changes across the codebase. All required fields are correctly mapped to the RecordConsumeLogParams struct.

relay/channel/openai/relay-openai.go (2)

127-133: Excellent type safety improvement!

The refactoring from map lookup with type assertion to direct field access on the typed ChannelSettings struct significantly improves type safety and code readability. The logic remains functionally equivalent while eliminating potential runtime type errors.

---

203-205: Consistent type safety improvement.

This change maintains consistency with the refactoring pattern applied elsewhere in the function, replacing map-based access with direct typed field access.

relay/common/relay_info.go (2)

100-100: Excellent architectural improvement!

Changing the ChannelSetting field from map[string]interface{} to dto.ChannelSettings provides strong typing and eliminates runtime type assertion errors throughout the codebase.

---

280-283: Clean implementation of typed context retrieval.

The use of the generic GetContextKeyType[dto.ChannelSettings] function maintains type safety when retrieving channel settings from the context, completing the typed refactoring chain.

controller/channel-test.go (1)

176-188: LGTM! Completes the consistent refactoring pattern.

The structured parameter approach is properly implemented in the test context, maintaining consistency with the broader codebase refactoring. The hardcoded userId=1 is appropriate for test scenarios, and all other fields are correctly mapped.

service/quota.go (3)

212-226: LGTM! Excellent refactoring to use typed struct parameters.

The refactoring from multiple positional parameters to a single RecordConsumeLogParams struct improves code maintainability and reduces the likelihood of parameter ordering errors. All field mappings are correct and consistent with the struct definition.

---

302-316: Clean refactoring with consistent parameter mapping.

The struct-based approach provides better type safety and self-documenting code. The parameter mappings are correctly preserved from the original function signature.

---

414-428: Consistent refactoring approach across audio consumption logging.

The change aligns with the broader refactoring pattern and maintains all necessary logging information while improving code organization.

relay/relay-mj.go (4)

37-44: Excellent improvement in proxy configuration access.

The change from map lookup with type assertion to direct typed field access (channel.GetSetting().Proxy) eliminates potential runtime errors and improves code readability. This aligns well with the broader refactoring to use strongly typed channel settings.

---

177-177: Good consolidation of context data access.

The commented-out context retrieval suggests that this data is now accessed through the relayInfo struct, which is a cleaner approach that centralizes data access and reduces context dependency.

---

223-233: Consistent logging parameter refactoring.

The struct-based parameter passing for RecordConsumeLog follows the same pattern established across the codebase, improving maintainability and type safety.

---

529-539: Well-structured logging parameter organization.

The refactoring maintains all necessary logging information while providing better organization through the typed struct approach.

model/channel.go (3)

518-527: Excellent addition of settings validation.

The new ValidateSettings() method provides essential validation for channel settings by ensuring the JSON can be properly unmarshaled into the typed dto.ChannelSettings struct. This will catch configuration errors early and prevent runtime issues.

---

529-538: Great improvement in type safety for channel settings.

Changing the return type from a generic map to dto.ChannelSettings eliminates the need for type assertions and provides compile-time safety for accessing channel configuration properties.

---

540-547: Consistent typed approach for setting channel configuration.

The method now accepts a strongly typed dto.ChannelSettings parameter, ensuring type safety and eliminating potential runtime errors from incorrect map key usage.

model/log.go (2)

139-153: Well-designed parameter struct with comprehensive field coverage.

The RecordConsumeLogParams struct effectively consolidates all logging parameters into a single, well-documented type. The JSON tags are appropriate and the field types match the original function parameters, ensuring no data loss during the refactoring.

---

155-204: Excellent refactoring that dramatically improves function maintainability.

The transformation from 13+ individual parameters to a single typed struct makes the function much more maintainable and less error-prone. The logging statement improvement (using common.GetJsonString(params)) provides better debugging information, and all field accesses are correctly updated to use the struct fields.

✨ Finishing Touches

• 📝 Generate Docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.