feat(microservices): add custom validation pipe #309
Conversation
Summary by CodeRabbit
WalkthroughThe changes introduce a customizable validation mechanism into the microservices module. A new Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant PipeMiddleware
participant Ctx
participant Config
participant CustomValidator
Client->>PipeMiddleware: Send request with payload
PipeMiddleware->>Ctx: ctx.Scan(payload)
Ctx->>Config: Get CustomValidation
Ctx->>CustomValidator: CustomValidation(payload)
CustomValidator-->>Ctx: Validation result (error or nil)
Ctx-->>PipeMiddleware: Return validation result
PipeMiddleware-->>Client: Continue or return error
Possibly related issues
Possibly related PRs
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed 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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
microservices/config.go(2 hunks)microservices/ctx.go(2 hunks)microservices/pipe.go(1 hunks)microservices/pipe_test.go(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
microservices/pipe_test.go (2)
microservices/config.go (1)
Config(17-26)dto/validator/scanner.go (1)
Scanner(14-180)
microservices/ctx.go (1)
microservices/config.go (1)
Config(17-26)
🔇 Additional comments (10)
microservices/pipe.go (1)
19-19: LGTM! Good architectural improvement with dependency inversion.The change from direct
validator.Scanner(payload)toctx.Scan(payload)nicely abstracts the validation logic behind the context interface, making validation customizable through configuration while maintaining the same error handling flow.microservices/pipe_test.go (2)
14-14: LGTM! Import added for explicit validation configuration.The validator import is needed since the test now explicitly configures the CustomValidation field.
79-81: LGTM! Test properly exercises the new validation mechanism.The explicit configuration of
CustomValidation: validator.Scannerensures that the test exercises the new context-based validation approach while maintaining backward compatibility with the existing validation behavior.microservices/ctx.go (2)
19-19: LGTM! Interface extension enables configurable validation.The addition of
Scan(val any) errorto the Ctx interface provides a clean abstraction for validation operations.
90-92: LGTM! Clean delegation to configured validation function.The implementation correctly delegates to the
CustomValidationfunction from the service configuration, enabling flexible validation strategies while maintaining a consistent interface.microservices/config.go (5)
8-8: LGTM! Import added for improved config merging.The common package import is needed for the
MergeStructfunction used in the updatedParseConfig.
11-11: LGTM! Import needed for default validation configuration.The validator package import is required since
DefaultConfignow setsCustomValidationtovalidator.Scanner.
25-25: LGTM! Config struct extended with validation field.The addition of
CustomValidation core.PipeFncfield enables configurable validation logic throughout the microservices framework.
41-41: LGTM! Sensible default maintains backward compatibility.Setting
CustomValidation: validator.Scanneras the default ensures existing code continues to work without changes.
82-84: LGTM! CustomValidation field properly handled in merge logic.The nil check and assignment for
CustomValidationfollows the same pattern as other configurable fields.
| if len(cfg[0].Header) > 0 { | ||
| for k, v := range cfg[0].Header { | ||
| for k, v := range mergeConfig.Header { | ||
| defaultConfig.Header[k] = v | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix inconsistent merge logic for Header field.
The Header field handling is inconsistent with other fields - it uses cfg[0].Header instead of mergeConfig.Header like other fields.
- if len(cfg[0].Header) > 0 {
- for k, v := range mergeConfig.Header {
+ if len(mergeConfig.Header) > 0 {
+ for k, v := range mergeConfig.Header {
defaultConfig.Header[k] = v
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if len(cfg[0].Header) > 0 { | |
| for k, v := range cfg[0].Header { | |
| for k, v := range mergeConfig.Header { | |
| defaultConfig.Header[k] = v | |
| } | |
| } | |
| if len(mergeConfig.Header) > 0 { | |
| for k, v := range mergeConfig.Header { | |
| defaultConfig.Header[k] = v | |
| } | |
| } |
🤖 Prompt for AI Agents
In microservices/config.go around lines 57 to 61, the merge logic for the Header
field incorrectly checks the length of cfg[0].Header instead of
mergeConfig.Header, causing inconsistency with other fields. Update the
condition to check the length of mergeConfig.Header and ensure the loop iterates
over mergeConfig.Header to maintain consistent merge behavior.
| if mergeConfig.ErrorHandler == nil { | ||
| defaultConfig.ErrorHandler = DefaultErrorHandler(cfg[0].Logger) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Fix inconsistent reference in ErrorHandler logic.
The code uses cfg[0].Logger instead of mergeConfig.Logger when creating the default error handler, which is inconsistent with the merge approach.
if mergeConfig.Logger != nil {
defaultConfig.Logger = mergeConfig.Logger
if mergeConfig.ErrorHandler == nil {
- defaultConfig.ErrorHandler = DefaultErrorHandler(cfg[0].Logger)
+ defaultConfig.ErrorHandler = DefaultErrorHandler(mergeConfig.Logger)
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if mergeConfig.ErrorHandler == nil { | |
| defaultConfig.ErrorHandler = DefaultErrorHandler(cfg[0].Logger) | |
| } | |
| if mergeConfig.Logger != nil { | |
| defaultConfig.Logger = mergeConfig.Logger | |
| if mergeConfig.ErrorHandler == nil { | |
| defaultConfig.ErrorHandler = DefaultErrorHandler(mergeConfig.Logger) | |
| } | |
| } |
🤖 Prompt for AI Agents
In microservices/config.go around lines 69 to 71, the code incorrectly uses
cfg[0].Logger instead of mergeConfig.Logger when assigning the default error
handler. Update the code to use mergeConfig.Logger to maintain consistency with
the merged configuration approach.
No description provided.