Closed mlaflamm closed 4 months ago
This is a very bad bug, and this PR seems to resolve the issues we were having with it. Would love if @davidyaha could get this merged.
Hey @mlaflamm Thanks for catching and fixing this! Sorry for my absence in the past months, I would like to review and merge this but I can't seem to find the time.
I've added @elibosley as a reviewer (it only let me put him here as he is the only commenter) if 1 more person other than @elibosley (maybe @jstaro) could review, I would feel more comfortable with merging and releasing a new version.
Does that work for everyone involved?
BTW, I do think this might be able to be resolved on the using library but I think this lib should also have safety measures to such scenarios as it is kind of a pain to debug and find the issue. so again thanks @mlaflamm for going after it!
Since this has been approved by everyone who needed to, can we merge this and push out an update?
can we merge this one?
@davidyaha can you merge it ?
@elibosley @bradens @jainshripal can you merge this fix in?
Hi, can we ship this? thanks 🙏
Thanks everyone! Sorry again for my absence.
Fix for #598
I created a unit test that reproduces the scenario described in the issue. This is unfortunately a convoluted test. Only the subscribe/unsubscribe flow is exercised. No message delivery is attempted.
As for the fix, we keep a pending state per channel,
subsPendingRefsMap
, before a new remote subscribe call is made to redis. That state is removed once the redis call is completed. The state keeps track of the subscription initiated while the redis call is in flight. The state also keeps a reference to the initial subscription promise.I had to use a deferred promise in the state. :crying_cat_face: The state must be initialized before executing the promise but the execution is done in the promise constructor.