-
Notifications
You must be signed in to change notification settings - Fork 7
use for await instead of stream.on #360
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
WalkthroughReplaces the consumer's event-driven per-message Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Init as init()
participant Consumer as AbstractKafkaConsumer
participant Stream as ConsumerStream
participant Processor as consume(msg)
participant Errors as handlerError / stream error
rect rgb(240,248,255)
Note over Init,Stream: Old flow (event-driven)
Init->>Stream: stream.on('data', handler)
Stream->>Processor: emit 'data' (per message)
Processor->>Processor: process message
end
rect rgb(245,255,240)
Note over Init,Consumer: New flow (async sequential)
Init->>Consumer: handleSyncStream(stream)
Consumer->>Consumer: for await (msg of stream)
Consumer->>Processor: consume(msg)
Processor->>Processor: process message
Consumer->>Errors: .catch(handlerError)
end
rect rgb(255,250,240)
Note over Stream,Errors: Error events preserved
Stream->>Errors: stream.on('error', ...)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
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 |
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
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/kafka/lib/AbstractKafkaConsumer.ts(1 hunks)packages/kafka/test/consumer/PermissionConsumer.spec.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
packages/kafka/test/consumer/PermissionConsumer.spec.ts (2)
packages/kafka/test/publisher/PermissionPublisher.ts (1)
PermissionPublisher(18-32)packages/kafka/test/consumer/PermissionConsumer.ts (1)
PermissionConsumer(37-97)
packages/kafka/lib/AbstractKafkaConsumer.ts (1)
packages/kafka/lib/types.ts (2)
DeserializedMessage(46-51)SupportedMessageValues(42-44)
🔇 Additional comments (2)
packages/kafka/lib/AbstractKafkaConsumer.ts (2)
214-218: Excellent refactoring for flow control and backpressure.Replacing the event-driven
stream.on('data')handler with the asynchandleSyncStreammethod successfully addresses the PR objectives. The.catch(this.handlerError)ensures errors in the async iteration are properly routed to the existing error handling mechanism.
223-232: LGTM! Thefor awaitloop provides natural backpressure.This implementation correctly:
- Waits for each message to be fully processed before fetching the next one (preventing OOM from message accumulation)
- Provides backpressure by suspending stream reads during handler execution
- Ensures sequential processing without race conditions
- Handles stream termination gracefully when
close()is calledThe type cast on line 229 is safe and necessary to narrow from the stream's generic
objecttype to the specificSupportedMessageValues<TopicsConfig>type.
Problem
The Kafka consumer was processing messages without flow control, which could lead to:
Solution
Added controlled data fetching by using
for awaitinstead ofstream.on('data')which is not respecting promises.Summary by CodeRabbit
Refactor
Tests
Chores
✏️ Tip: You can customize this high-level summary in your review settings.