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

As a learning exercise, I attempted a fix. No idea if this is “correct”, but testing in local build it seem to do the right thing – on reservation error, I can still click join button again and it retries the join.

FYI, just noticed the same issue with muc_max_occupants – users see the error notification, after which the nothing happens with join button (same error in js console).

No idea if my PR above is on the right track. But if it is, happy to extend that to also cover CONFERENCE_MAX_USERS.

Now I’m wondering what other error conditions could fall under same category…

Nice catch! Maybe there are more cases there …

Hey, @shawn can you test this https://github.com/jitsi/lib-jitsi-meet/pull/1878 with the reservation error?
For the max_users it needs a jitsi-meet change, which I will follow up when we merge this.

I tried with a local build using your ljm branch and latest master for jitsi-meet, and I get the following error when reservation fails:

UnhandledError: Strophe: TypeError: Cannot read properties of undefined (reading 'doLeave')
Logger.js:154 2022-02-09T21:06:56.717Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>:  UnhandledError: Strophe: TypeError: Cannot
 read properties of undefined (reading 'doLeave')
    at r.<anonymous> (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:199317)
    at r.emit (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:100433)
    at xs._allocateConferenceFocusError (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:261648)
    at https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:261096
    at I.Handler.handler (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:616636)
    at I.Handler.run (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:611935)
    at https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:620373
    at Object.forEachChild (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:603603)
    at I.Connection._dataRecv (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:620222)
    at N.Websocket._onMessage (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:649452) Script: null Line: null Column: nul
l StackTrace:  Error: Strophe: TypeError: Cannot read properties of undefined (reading 'doLeave')
    at r.<anonymous> (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:199317)
    at r.emit (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:100433)
    at xs._allocateConferenceFocusError (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:261648)
    at https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:261096
    at I.Handler.handler (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:616636)
    at I.Handler.run (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:611935)
    at https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:620373
    at Object.forEachChild (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:603603)
    at I.Connection._dataRecv (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:620222)
    at N.Websocket._onMessage (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:649452)
    at Object.Hr.ot.Strophe.log (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:355664)
    at Object.fatal (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:608868)
    at Object._handleError (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:608259)
    at I.Handler.run (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:611963)
    at https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:620373
    at Object.forEachChild (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:603603)
    at I.Connection._dataRecv (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:620222)
    at N.Websocket._onMessage (https://localhost:8080/libs/lib-jitsi-meet.min.js?v=5764:2:649452)
r @ Logger.js:154

Subsequent clicks result in the same “coference with the same name has already been created” error.

Update:
I inspected conference.connection at this point and it looks to be a JitsiConnection object which does not have an emuc property, hence the error.

However, if I change that to conference.connection.xmpp.connection.emuc.doLeave(conference.room.roomjid)
then it seems to work as expected.

1 Like

Thanks.

I guess same and for conference.xmpp.connection.emuc.doLeave(conference.room.roomjid);

Yup. Just tested the updates and it seems to work. Thanks!

I will close my PR.

I’ve just tested handling of max_user errors using latest jitsi-meet which includes #110095, and I was able to try join after each max_user failure :muscle:.

However, on each failed join I also see the following error in JS console.

Warning: Encountered two children with the same key, `The`. Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version.

react-dom.development.js:67 Warning: Encountered two children with the same key, The. Keys should be unique so that components maintain their identity across updates. Non-unique keys may cause children to be duplicated and/or omitted — the behavior is unsupported and could change in a future version.
at Message (https://localhost:8080/libs/app.bundle.min.js?v=5764:191235:5)
at p
at div
at EmotionCssPropInternal
at div
at render
at EnteringMotion (https://localhost:8080/libs/app.bundle.min.js?v=5764:26180:23)
at FadeIn (https://localhost:8080/libs/app.bundle.min.js?v=5764:26084:23)
at ExitingPersistence (https://localhost:8080/libs/app.bundle.min.js?v=5764:25890:26)
at div
at EmotionCssPropInternal
at Expander (https://localhost:8080/libs/app.bundle.min.js?v=5764:25058:23)
at div
at EmotionCssPropInternal
at Consumer (https://localhost:8080/libs/app.bundle.min.js?v=5764:42202:26)
at Flag (https://localhost:8080/libs/app.bundle.min.js?v=5764:25468:30)
at Notification (https://localhost:8080/libs/app.bundle.min.js?v=5764:238042:1)
at I18nextWithTranslation (https://localhost:8080/libs/app.bundle.min.js?v=5764:131006:92)
at Transition (https://localhost:8080/libs/app.bundle.min.js?v=5764:135502:5)
at CSSTransition (https://localhost:8080/libs/app.bundle.min.js?v=5764:134962:5)
at div
at TransitionGroup (https://localhost:8080/libs/app.bundle.min.js?v=5764:136141:5)
at div
at div
at StyledComponent (https://localhost:8080/libs/app.bundle.min.js?v=5764:149389:9)
at ThemeProvider (https://localhost:8080/libs/app.bundle.min.js?v=5764:149063:5)
at Provider (https://localhost:8080/libs/app.bundle.min.js?v=5764:42224:68)
at AtlaskitThemeProvider (https://localhost:8080/libs/app.bundle.min.js?v=5764:41427:86)
at NotificationsContainer (https://localhost:8080/libs/app.bundle.min.js?v=5764:238339:5)
at WithStyles (https://localhost:8080/libs/app.bundle.min.js?v=5764:54071:31)
at ConnectFunction (https://localhost:8080/libs/app.bundle.min.js?v=5764:132479:68)
at I18nextWithTranslation (https://localhost:8080/libs/app.bundle.min.js?v=5764:131006:92)
at div
at div
at Conference (https://localhost:8080/libs/app.bundle.min.js?v=5764:209197:5)
at I18nextWithTranslation (https://localhost:8080/libs/app.bundle.min.js?v=5764:131006:92)
at ConnectFunction (https://localhost:8080/libs/app.bundle.min.js?v=5764:132479:68)
at div
at StyledComponent (https://localhost:8080/libs/app.bundle.min.js?v=5764:149389:9)
at ThemeProvider (https://localhost:8080/libs/app.bundle.min.js?v=5764:149063:5)
at Provider (https://localhost:8080/libs/app.bundle.min.js?v=5764:42224:68)
at AtlaskitThemeProvider (https://localhost:8080/libs/app.bundle.min.js?v=5764:41427:86)
at ThemeProvider (https://localhost:8080/libs/app.bundle.min.js?v=5764:53216:24)
at JitsiThemeProvider (https://localhost:8080/libs/app.bundle.min.js?v=5764:199971:18)
at ConnectFunction (https://localhost:8080/libs/app.bundle.min.js?v=5764:132479:68)
at Provider (https://localhost:8080/libs/app.bundle.min.js?v=5764:132274:24)
at I18nextProvider (https://localhost:8080/libs/app.bundle.min.js?v=5764:130189:19)
at App (https://localhost:8080/libs/app.bundle.min.js?v=5764:164276:1)

The error does not affect the ability of the user to rejoin, and is not present if there is no max_user error.

FYI I have seen this error quite a lot while testing the PR for lobby chat, it seems that it’s triggered every time a word appears 2 times in a chat message, as for example ‘the user enter the room’ will do it. So it’s possibly unrelated, and it was totally harmless in this case.