removeStickyEvent(...) does not remove event the first time.

[onyxmueller]

I'm noticing a behavior where [EventBus.getDefault()].removeStickyEvent(...) does not remove the event immediately, but follow-up calls do. This occurs with both usages (event instance and class type). Is this a bug? Or is there a scenario where this can occur that I am not understanding?

[doridori]

I heard a colleague complaining of this also but I didn't have time to look into it myself

[pmecho]

I'm seeing the same behavior, particularly after a configuration change. The onEvent callback removes the sticky event but the callback gets called an additional time after the configuration change. After that, it appears that the sticky event is removed and all is well.

[pmecho]

This is due to the event being posted before it is added to the sticky event map:

public void postSticky(Object event) {
    post(event);
    synchronized (stickyEvents) {
        stickyEvents.put(event.getClass(), event);
    }
}

I guess this is a drawback of sticky events and we should be looking for consumable events as was hinted at for a future release.

[doridori]

Couldnt these just be flipped round?

[greenrobot]

Posting after putting the event ("flipping around") makes sense to me. I'll make the change and think about a unit test for this scenario.

[doridori]

Cool thanks :) Is there any way to unit test async methods without using a timeout? I wrote a helper class for this but I imagine there is a better way. Dont worry if you are too busy to answer this as I will look up but interested to hear your approach.

[onyxmueller]

This sounds like it should do the trick. Please let me know when the changes have been implemented and I will test to confirm it works as well. Thanks.

[greenrobot]

Fixed in 16ba793 with unit test.