4.x: Fix consumer retention in cache() upon subscribe-cancel race - #8283
Conversation
🐷 TruffleHog + Entropy Beauty ScanAverage entropy of changed code: 4.46 bits/char Changed files entropy: ✅ No secrets or suspicious high-entropy strings found. Mid-4 beauty heuristic in action — powered by our entropy chats! 😊 |
🐷 TruffleHog + Entropy Beauty ScanAverage entropy of changed code: 4.492 bits/char Changed files entropy: ✅ No secrets or suspicious high-entropy strings found. Mid-4 beauty heuristic in action — powered by our entropy chats! 😊 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.x #8283 +/- ##
============================================
- Coverage 98.65% 98.61% -0.04%
- Complexity 7147 7148 +1
============================================
Files 824 824
Lines 50784 50789 +5
Branches 6907 6910 +3
============================================
- Hits 50101 50087 -14
- Misses 473 481 +8
- Partials 210 221 +11 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
When the incoming
SubscriberorObservercancels while in their respectiveonSubscribeor race it afterwards, the operator could retain it in its consumer tracking array indefinitely, depending on the cached source.The fix is, like many other place is to after add, check if the consumer cancelled and then manually remove them for sure.
In addition, apparently the test
cancelledUpFrontConnectAnywaywas missing fromObservableCacheTestwhich is important because thecacheoperator is expected to connect, even with dead consumers.Privately reported as an ??? exploit ???
@August829
RxJava-09: ObservableCache/FlowableCache Register Consumers Before Checking Disposed State — Self-Disposing Subscribers Permanently Retained
🛑 Do not report bugs as security exploits. 🛑