-
Notifications
You must be signed in to change notification settings - Fork 2
feat(microservice): currently deprecated rpc in microservice #335
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Summary by CodeRabbit
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
microservices/store.go (1)
8-27: Reintroduce per-event subscriber indexingBy switching
Store.Subscribersfrom a map to a single slice (Line 8) we lose the per-event bucketing that previously gave us near-constant-time lookups. Unless there’s a new index elsewhere, everyPublishnow has to linearly scan all handlers to find a match, which is a major regression on a hot path once the subscriber count grows. Please keep a hashed structure (or add an equivalent index) so dispatch cost scales with the number of listeners for the specific event, not with all registered events.type Store struct { - Subscribers []*SubscribeHandler + Subscribers map[string][]*SubscribeHandler } … Name: STORE, - Value: &Store{}, + Value: &Store{ + Subscribers: make(map[string][]*SubscribeHandler), + }, }) … handlerModule.NewProvider(core.ProviderOptions{ Name: name, - Value: &Store{}, + Value: &Store{ + Subscribers: make(map[string][]*SubscribeHandler), + }, })microservices/tcp/tenant_test.go (1)
74-74: Fix login event name to avoid duplicate handlers firingPublishing
user.*makes the TCP server treat this as a wildcard and invoke every subscriber whose name starts withuser.(seehandlerPubSub), which means theuser.createdhandler runs again on login and appends an extra directory entry. Switch this to the concreteuser.logintopic so only the intended handler executes.- go client.Publish("user.*", user, microservices.Header{"x-tenant-id": tenantID}) + go client.Publish("user.login", user, microservices.Header{"x-tenant-id": tenantID})microservices/tcp/server.go (1)
110-116: Call every subscriber registered for an exact event
IndexFuncreturns only the first matching handler, so any additional subscribers registered for the same event are silently skipped—a regression from the previous map-based dispatch. Iterate and invoke all exact matches instead.- findEvent := slices.IndexFunc(handlers, func(e *microservices.SubscribeHandler) bool { - return string(e.Name) == msg.Event - }) - if findEvent != -1 { - sub := handlers[findEvent] - sub.Handle(svc, msg) - } + for _, sub := range handlers { + if string(sub.Name) == msg.Event { + sub.Handle(svc, msg) + } + }
🧹 Nitpick comments (1)
microservices/pipe_test.go (1)
60-62: Fix the log label in the failure handlerLine 61 still prints
"User Created Data"even though this is theuser.failedhandler. That makes it hard to distinguish successful vs failed flows in the logs whenever both events fire. Please adjust the message so we can triage failures quickly.- fmt.Println("User Created Data:", ctx.Get(microservices.PIPE)) + fmt.Println("User Failed Data:", ctx.Get(microservices.PIPE))
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
microservices/client_test.go(1 hunks)microservices/ctx_test.go(0 hunks)microservices/exception_test.go(2 hunks)microservices/fnc.go(0 hunks)microservices/guard_test.go(2 hunks)microservices/handler.go(1 hunks)microservices/handler_test.go(2 hunks)microservices/message.go(0 hunks)microservices/middleware_test.go(2 hunks)microservices/pipe_test.go(3 hunks)microservices/store.go(3 hunks)microservices/tcp/client.go(3 hunks)microservices/tcp/error_test.go(1 hunks)microservices/tcp/server.go(1 hunks)microservices/tcp/tenant_test.go(3 hunks)microservices/type.go(0 hunks)
💤 Files with no reviewable changes (4)
- microservices/type.go
- microservices/fnc.go
- microservices/message.go
- microservices/ctx_test.go
🧰 Additional context used
🧬 Code graph analysis (9)
microservices/pipe_test.go (2)
microservices/pipe.go (2)
PayloadParser(37-38)PIPE(9-9)microservices/ctx.go (1)
Ctx(11-20)
microservices/store.go (1)
microservices/subscriber.go (1)
SubscribeHandler(9-13)
microservices/handler_test.go (1)
microservices/ctx.go (1)
Ctx(11-20)
microservices/middleware_test.go (2)
microservices/ctx.go (1)
Ctx(11-20)microservices/config.go (1)
Header(14-14)
microservices/client_test.go (1)
microservices/ctx.go (1)
Ctx(11-20)
microservices/handler.go (1)
microservices/subscriber.go (1)
SubscribeHandler(9-13)
microservices/tcp/tenant_test.go (2)
microservices/config.go (1)
Header(14-14)microservices/ctx.go (1)
Ctx(11-20)
microservices/tcp/client.go (3)
microservices/message.go (3)
EncodeMessage(15-29)Message(8-13)AssignHeader(47-56)microservices/config.go (2)
Config(16-24)Header(14-14)microservices/type.go (1)
ClientProxy(10-14)
microservices/guard_test.go (3)
microservices/guard.go (1)
Guard(8-8)microservices/ctx.go (1)
Ctx(11-20)microservices/config.go (1)
Header(14-14)
🔇 Additional comments (1)
microservices/middleware_test.go (1)
29-32: OnEvent migration matches the new event-driven handler API.Switching the registration to
OnEventkeeps the middleware flow aligned with the pub/sub semantics introduced in this PR. Nice catch on updating the test hook.
| payload, err := microservices.EncodeMessage(client, microservices.Message{ | ||
| Event: event, | ||
| Headers: microservices.AssignHeader(client.Config().Header, headers...), | ||
| Data: data, | ||
| }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix header type passed into EncodeMessage.
microservices.Message.Headers is declared as map[string]string (microservices/message.go, Lines 7-14), whereas AssignHeader returns microservices.Header. Without an explicit conversion, this line won’t compile. Let’s coerce the merged headers back to the concrete map type before building the message.
- payload, err := microservices.EncodeMessage(client, microservices.Message{
- Event: event,
- Headers: microservices.AssignHeader(client.Config().Header, headers...),
- Data: data,
- })
+ mergedHeaders := microservices.AssignHeader(client.Config().Header, headers...)
+ payload, err := microservices.EncodeMessage(client, microservices.Message{
+ Event: event,
+ Headers: map[string]string(mergedHeaders),
+ Data: data,
+ })📝 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.
| payload, err := microservices.EncodeMessage(client, microservices.Message{ | |
| Event: event, | |
| Headers: microservices.AssignHeader(client.Config().Header, headers...), | |
| Data: data, | |
| }) | |
| mergedHeaders := microservices.AssignHeader(client.Config().Header, headers...) | |
| payload, err := microservices.EncodeMessage(client, microservices.Message{ | |
| Event: event, | |
| Headers: map[string]string(mergedHeaders), | |
| Data: data, | |
| }) |
🤖 Prompt for AI Agents
In microservices/tcp/client.go around lines 50 to 54, the code passes
microservices.AssignHeader(...) (returns microservices.Header) directly into
Message.Headers which is declared as map[string]string; this causes a type
mismatch. Fix by coercing the result of AssignHeader back to the concrete map
type before building the message (e.g. assign the merged headers to a variable
and convert it to map[string]string or directly wrap the call in a conversion),
then use that map[string]string as Message.Headers.
No description provided.