KTOR-9561 Rethrow closedCause after copyTo#5634
KTOR-9561 Rethrow closedCause after copyTo#5634fru1tworld (fru1tworld) wants to merge 2 commits into
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)
📝 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.
Subsystem
ktor-io
Motivation
KTOR-9561 ByteReadChannel.copyTo does not propagate source closedCause on normal exit
Solution
Call
rethrowCloseCauseIfNeeded()in bothcopyTooverloads, matchingreadTo/readRemaining.