The fix that was applied earlier improved the reflection of initial presence, but introduced the original problem when reflecting offline presence.

This is being logged on debug:

I mean (from the clients perspective), this is what I observed:

Connect
Send <presence/>
Receive nothing
Send <presence/>
Receive <presence/>

Thanks, but what do you mean by 'A second presence stanza is received.' ?

I can reproduce this running openfire_2018-10-30.tar.gz by:

Connect
Send <presence/>
Expect <presence/> but don't receive it

A second presence stanza is received.

test case for the scansion test runner

I don't think the fix for ever completely worked. It is based on a presence broadcast that sends a presence update to all subscribed entities, as well as all resources of the same user that are available.

The problem lies in the fact that the presence update was 'recorded' in the client session only after this broadcast was done. When iterating over all client session to find resources that are available, the session from where the update originated, is still reporting the previous presence state (in case of a new session: unavailable).

To me, re-ordering events seem logical, and desirable for other reasons. It makes sense to first store the presence update in the client session, and only then broadcast the update.

With this fix, the test mentioned above now produces: