[API-879] Wait for listener deregistration requests #475
Conversation
With this PR, we will wait for all the listener deregistration requests to finish before returning `True` to the user. It is mainly a precaution to the possible problems that might result in services that expect sync removal of listeners. While doing that, I have also dived into one of our technical debts and corrected the implementation of the `combine_futures`. It now waits for all futures to complete in all scenarios, as it should be, and sets the result to the first exceptional completion, if some of the input futures complete as such.
There was a problem hiding this comment.
combine_futures looks perfect ✔️
deregister_listener seems to follow Java except a small difference.
And I have a small question: We pop from the local registration dictionary _active_registrations before receiving a successful deregistration response from the members. So, can there be an erroneous case where the member still thinks we have a listener registered and keep sending events?
|
@yemreinci Yes, correct. I think we discussed this a while ago during one of our standups, discussed various solutions for that problem, and reached this state. The client always removes its local listener registration, regardless of the listener deregistration request outcome. When a member sends an event that we don't know, we will simply ignore it, but as you said it will keep coming to the client |
With this PR, we will wait for all the listener deregistration
requests to finish before returning
Trueto the user.It is mainly a precaution to the possible problems that might result
in services that expect sync removal of listeners.
While doing that, I have also dived into one of our technical debts
and corrected the implementation of the
combine_futures.It now waits for all futures to complete in all scenarios, as it should be,
and sets the result to the first exceptional completion, if some of
the input futures complete as such.
Closes #448