feat: serialize dispatch per worker - #91
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 34f0c2c746
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Wait for in-flight calls to complete before closing pools | ||
| p.callsMu.Lock() | ||
| p.callsMu.Unlock() | ||
| p.activeCallsWG.Wait() |
There was a problem hiding this comment.
Bound shutdown wait for active calls
Shutdown now waits on p.activeCallsWG.Wait() before closing connections or stopping workers, so a long-running or hung in-flight call can block shutdown indefinitely. Because this method ignores its context.Context parameter, callers cannot time-bound this wait during rollout/termination, which can wedge service shutdown in production. Consider making this wait context-aware (or stopping workers before/while waiting) so shutdown remains bounded.
Useful? React with 👍 / 👎.
0f8a8ce to
29967bc
Compare
34f0c2c to
b7369b3
Compare
29967bc to
7c7a7c1
Compare
b7369b3 to
04469d9
Compare
Move activeCallsWG.Wait() inside the callsMu critical section to satisfy staticcheck SA2001 (empty critical section). The lock still serves as a barrier ensuring all in-progress Call() goroutines have completed their Add(1) before Wait() is called. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
MaxInFlightPerWorkerand keepMaxInFlightas global backpressure.Call/Shutdownconcurrency-safe.Changes
Calllifecycle withactiveCallsWGandcallsMu.MaxInFlightPerWorkerand wire through pool creation.Test plan
go test -v -race ./...