UX when reservation fails

Currently (v6726), when reservation plugin is used, a user who joins with a failed reservation sees a notification like so:

Unfortunately, from that point on the join button is still active but nothing happens with subsequent clicks of the join button.

This could be very confusing for users, especially since all other controls still work as usual (and the notification disappears after a while)

The only recovery is to reload the page.

The following errors show up in JS console on each click:

[JitsiConference.js] : A coference with the same name has already been created!
[conference.js] <Object.prejoinStart>: An error occurred while trying to join a meeting from the prejoin screen: Error: A coference with the same name has already been created!

Implementation wise, this “feels” like an unintended behaviour, i.e. conference state set up in the app but does not get rolled back if join fails due to reservation failures. But that’s just an unverified guess on my part.

Not sure what the correct outcome should be, but personally my preference would be:
a) Join button retries the join. Presumably the same notification will pop up for each failed join. Considering the case where someone joins too early and the join would be successful if retried shortly after.
b) Or, expose an onReservationFailure event so integrators can handle it to best suit their use case.

Thoughts?

This seems what it should happen. I guess the destroy of the room does not clear conference as expected in the internal state … is my guess and needs attention :slight_smile:

I may be reading this completely wrong, but it looks like isRoomCreated check in strophe.emuc.js is just checking existence of jid in this.rooms which is written by createRoom but not cleared if room creation fails.

Assuming possible, would it suffice to add an onReservationError handler that deletes this.room[jid]?

Isn’t this destroy message? If that is the case, this is handled lib-jitsi-meet/ChatRoom.js at 55a03ac1b52f85dcbd9bfe339690ad88436ac029 · jitsi/lib-jitsi-meet · GitHub

Are you talking about this reservation error?

This is fired when we send an IQ to jicofo, we do not join the room till we receive a successful response from jicofo.

I think the problem is in jitsi-meet, as there in the store we do intermediate state will join and we clear stuff on errors, for example lobby … conference_failed or something like that, and I just suspect not correctly handled … I was adding two fixes for some other cases in the last 2-3 months

I’m just wild guessing here :slight_smile:
The two fixes, maybe totally not relevant, but here are those:

I was back tracking from the “A coference with the same name has already been created!” error (easy to find because of the coference typo) and noticed it came from here:

The isRoomCreated does not actually check if muc exists and only if MucConnectionPlugin.room contains the room jid.

In the event that error iq is sent back from focus, I was wondering if that check is still valid because room not created but the cached value in strope.muc thinks it is already there.

p.s. I have to admit I don’t really know what I’m talking about. I’m just making guesses based on a quick glance at code I know nothing about. Apologies if this is just noise.

You are right, we create ChatRoom object(so this is stored in emuc) and we call join, which calls allocateConferenceFocus and it returns an error … and we never clean it … but I do not see cleaning it for anything else … so I’m not sure what is the correct fix … I can try to look at it, but not sure when I will have resources :slight_smile:

1 Like