Bootstrap on assignement and closing on revocation about franz-go HOT 4 CLOSED

If I'm reading this right, you'd like to build / destroy state in OnAssigned and OnRevoked, but building / destroying may return an error?

I think I'd try retrying on error within OnAssigned and OnRevoked, and if you reach a critical error, LeaveGroup. If either of your hooks take too long, the client will be forced from the group by Kafka as it is.

I'm not sure I fully understand the goal here, though?

from franz-go.

Yes you perfectly understood it :) I will try to clarify my use case a bit more precisely.
The goal might be for example a transactional counter, where you have a stateful compacted topic (containing the total count per partition) and stetaless topic (containing each event to count per partition).
On assignment, we bootstrap the state by reading the compacted topic to get the current total per partition (by kafka key) and then continue reading from the events topic (kafka streams-ish).
On a large number of counters, we would prefer using disk for storing states and this can cause errors (even consumption of the compacted topic can cause errors). Maybe, on such errors, it is arguable that we can consider this an unrecoverable error and to LeaveGroup or to panic after a number of retries.

from franz-go.

I think I can see a few potential ways of doing things.

If OnAssigned takes too long, then the client is booted from the group from Kafka. When you finally finish OnAssigned, you will immediately proceed to OnRevoked, and then once that finishes, the client will retry joining the group. So, if you are fine with potentially causing rebalances when OnAssign/OnRevoke takes too long, that's one option.

If you have an unrecoverable error in either OnAssigned or OnRevoked, then leaving the group is the best bet, because it doesn't make sense to rejoin the group.

If you want to stop progress in OnAssigned/OnRevoked if the member is booted (so, you're taking too long and then the client is kicked from the group), that's not currently possible. The context passed to the callbacks is the context for the group member itself, not for the session it is in. I can look into potentially changing this down the line if that would help.

But, if you have an error in the callback, I can't think of a solid thing to do when the callback returns if it was able to return an error. The only two options for the client itself are to leave the group or to continue within the group, and you can ensure that behavior manually by either calling LeaveGroup or not?

from franz-go.

Alright, thank you very much for your propositions. I'll give it a shot.

from franz-go.