Fix for an infinite loop in cooperative sticky assignor#4800
Conversation
|
I can confirm this works :) I applied it via a patch in rdkafka-ruby and was not able to trigger it anymore. Thank you! |
|
Thank you Maciej Mensfeld (@mensfeld) ! Couldn't push it earlier because we're reviewing company flows after the incident that happened to public repositories earlier in the month. |
|
No worries. You motivated me to finally craft ability to patch librdkafka for rdkafka-ruby so now I can also expose the needed fork-protect APIs for MacOS. Thank you for all your hard work 🙏 |
|
🎉 All Contributor License Agreements have been signed. Ready to merge. |
Pranav Rathi (pranavrth)
left a comment
Pranav Rathi (pranavrth)
left a comment
There was a problem hiding this comment.
Thanks. Please rebase and we should be good to merge.
airlock-confluentinc
Bot
force-pushed
the
dev_fix_cooperative_sticky_infinite_loop
branch
from
e6c8a1f to
583dc56
Compare
Pranav Rathi (pranavrth)
left a comment
Pranav Rathi (pranavrth)
left a comment
There was a problem hiding this comment.
LGTM!. We can add a test but I don't feel there is necessity of a test for this kind of bug.
|
Pranav Rathi (@pranavrth) I've been running a similar patch for this for weeks, I have specs in rdkafka-ruby and karafka. This solves it as I was able to reproduce it on my side in 100%. |
when potential topic partitions are less than currently assigned ones.
airlock-confluentinc
Bot
force-pushed
the
dev_fix_cooperative_sticky_infinite_loop
branch
from
583dc56 to
993aa1e
Compare
|
Maciej Mensfeld (@mensfeld) - I was saying that we don't need a test for this kind of trivial bug. |
Emanuele Sabellico (emasab)
deleted the
dev_fix_cooperative_sticky_infinite_loop
branch
3 participants
when potential topic partitions are less than number of members.
Closes #4783