KTOR-9561 Rethrow closedCause after copyTo - #5634
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughA new private helper ChangesClose-cause propagation in ByteChannel.awaitContent
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Bruce Hamilton (bjhham)
left a comment
There was a problem hiding this comment.
Could you try the fix proposed in the YT ticket:
rethrowCloseCauseIfNeeded() should be made private to ByteChannel and called at the end of awaitContent() (after sleepWhile exits), so that any cancellation cause is always propagated regardless of whether the caller was suspended or executing between iterations. This would make copyTo (and all other readers built on awaitContent()) correct by default.
This is a more central refactor than the immediate workaround and should be addressed in a dedicated change.
This would ensure all looped flows like this are covered.
Bruce Hamilton (bjhham)
left a comment
There was a problem hiding this comment.
fru1tworld (@fru1tworld) thx, please rebase and resolve conflicts
c984ca4 to
7b0952e
Compare
Subsystem
ktor-io
Motivation
KTOR-9561 ByteReadChannel.copyTo does not propagate source closedCause on normal exit
Solution
Call
rethrowCloseCauseIfNeeded()in bothcopyTooverloads, matchingreadTo/readRemaining.