Repository navigation
Read a pull subscription's stream and consumer names from its consumer info - #183
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthrough
ChangesPull subscription name assignment
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Medium Merge Risk: ⚪ Minimal · up to The change addresses the reported pull-subscription lifetime issue, with no identified issue requiring resolution before merge. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 2 systems. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
…r info Without options.stream, pullSubscribe looks the stream name up by subject and frees it on return, but the PullSubscription kept that slice, so every fetch() built its request subject from freed memory. The subscription already owns the consumer info, which carries both names as the server reports them, so drop the separate stream_name and consumer_name fields and have fetch() read them from there. The old consumer name chain (config name, then durable name, then the caller's durable) always resolved to the same value as the info's name.
72999d4 to
322c404
Compare
…r info (#183) Without options.stream, pullSubscribe looked the stream name up by subject and freed it on return, but the PullSubscription kept that slice, so every fetch() built its request subject from freed memory. The subscription already owns the consumer info, which carries both names as the server reports them, so the separate stream_name and consumer_name fields are gone and fetch() reads them from there. Fixes #182.
Fixes #182.
Without
options.stream,pullSubscribelooks the stream name up by subject and frees it when it returns. The returnedPullSubscriptionkept that slice, so everyfetch()built itsCONSUMER.MSG.NEXTsubject from freed memory.The subscription already owns the consumer info, and that carries both names as the server reports them. This removes the separate
stream_nameandconsumer_namefields, andfetch()readsconsumer_info.value.stream_nameandconsumer_info.value.nameinstead. nats.c and nats.go also take the consumer name from the info'sName.The old consumer name chain (
config.name, thenconfig.durable_name, then the caller'sdurable) always resolved to the same value. nats-server sets the info's name fromDurableorNameand rejects a config where the two differ, so thedurablefallback was never reached.Breaking change:
PullSubscription.stream_nameand.consumer_nameare gone. Useconsumer_info.value.stream_nameand.nameinstead.Testing
pullSubscribewithout.stream, thenfetch(). It fails onmain(the freed name produces an invalid subject) and passes with this change../check.shpasses.