Inconsistent state of reserved conference

Sorry, I’ve been away so could not give this thread proper thought.

I’ll try to summarise my understanding of how this works, and we can pinpoint where this does not work as expected or what needs fixing.

On Prosody restarts/failures:

So when prosody dies or is restarted, users would get disconnected and rejoin the same shard after it comes back online or they may get migrated to a different shard with a different prosody server.

To be able to handle both cases consistently, the assumption is that room and reservation data from the previous session is not preserved and no longer available, so the reconnection behaves the same way as everyone joining a new room. The reservation plugin intercepts conference requests from users, and will first make the reservation API call to confirm room creation is allowed before relaying them to Jicofo, and everything works as usual from then on.

In this situation, the API endpoint could just return a 200 response the same way it does during the initial joins and it should work as usual. Or, it could return a 409 with a conflict_id and the plugin will follow this up with GET call to retrieve reservation details. The eventual outcome for either case is exactly the same as far as the plugin is concerned, and the 409 handling was implemented mainly for backward compatibility old reservations implementation. (On my deployments, I don’t bother with the 409s and always return 200, which means I also don’t need to implement the GETs).

The error message in your screenshot implies that you are returning 409 but the response payload appears to be unparseable or inconsistent with expectations. We can drill further into that if you want to make that work, but in theory you don’t need that at all.

On user reconnect:

If all users leave the conference and then rejoins for whatever reason but prosody remains operational, then behaviour depends on how soon they reconnect.

The reservation plugin caches reservation responses rooms until rooms are destroyed or when the reservations expire (checked every 60s), and while the data is still cached it will not issue new API calls for conference requests and simply relay them on to Jicofo.

And because rooms are only deleted 60s after everyone leaves, there is a grace period after everyone leaves where reservation data is still cached and prosody rooms still persist. Users rejoin the same room and reservation plugin does nothing.

After that grace period, reconnections will behave the same way as a new room.


Does this help? Does it work for your use case?

1 Like

This explanation clears a lot of things for me. Thank you for the detailed information.

Also, where in the reservation plugin does it cache the reservation responses room?

Reservation data is stored in a table keyed by room_jid as a var local to the module. The data structure is initialised when first accessed:

On API response, the values are populated using one of the set_status_* methods on the RoomReservation object:

If you’re interested in walking through the code, it might help to take a look the implementation diagram here: Reservation System setup | Jitsi Meet