When leaving a call the chat requests are canceled

[nickvergessen]

Steps to reproduce

1. Create a conversation
2. Start a call
3. Leave the call

Expected behaviour

Actual behaviour

It seems both, the chat request in the right sidebar as well as the one in the main view get canceled, while th emain one is required to persist:

[PVince81]

I think I know: when I moved the cancellation to the store, I'm reusing the same attribute for any request.
This is similar to #5699.

Might need to map the attribute to a specific request.

On the other hand, here it's a bit special because we have two component instances based on the same list, so in theory only a single request is needed and no cancellation. It's the MessagesList that triggers cancellation when being destroyed, maybe that needs to happen elsewhere.

[PVince81]

Ok, I tried splitting the cancel functions by token and it doesn't help. Because this is not reason.

The first cancelled:

• call is triggered from the "chatIdentifier" watcher, immediately when creating the view, and leads to handleStartGettingMessagesPreCondition
• cancellation also triggered from there

The second cancelled:

• call comes from the "setTimeout()" in getNewMessages()
• cancellation triggered by MessagesList's beforeDestroy

So the old view cancels while being destroyed, and the new MessagesList cancels again while setting itself up.
But it seems that the main view gets created before the sidebar vue gets destroyed, so there's an overlap.

Now if the chatIdentifier didn't really change, I don't see why an initial fetch would need to cancel an old call. If there was one pending it could just reuse it. To detect an initial chatIdentifier one can check that there's no oldValue set.

I'll give this a try.

[PVince81]

seems this is more complex than I thought.

the expectation seems to be that we want to cancel and refetch whenever one of "token", "isParticipant" and "isInLobby" changes, but ideally not cancel and refetch the same thing

some kind of can of worms...

a quick workaround would be to tie those fetch and cancel requests to a vue id to simulate the old behavior where a request was tied to a vue instead of being "global"

[PVince81]

ideal would be to decouple the call from the MessagesList vue and have it running separately.

• this way when we switching between right sidebar and main view, the call continues, this would save some extra requests when starting or leaving the call

• need to make sure that we do cancel the polling whenever the user switches rooms (token change), participant state changes or lobby state changes, as it seems to be defined already by the chatIdentifier which is made of these three values

• maybe move the polling logic to the store and have "startPollLookForNewMessages" and "stopPollLookForNewMessages". Internally we need to track to what "chatIdentifier" this is attached to. If it changes, we need to cancel when calling "startPollLookForNewMessages" action with different params, otherwise we don't cancel.

• only call "stopPollLookForNewMessages" when moving away from any conversation

• potential existing bug: it seems we don't store the timers, so if a new getNewMessages() call is done separately while the timeout is running, we might end up with two calls running in parallel (could be investigated in parallel)

  • if we have all this in the store, we could easily store the timers there centrally and reset them in case of cancellation or newly started poll

[PVince81]

• bug in current code: the first getNewMessages(followInNewMessages) is expecting to scroll to bottom after fetching messages. but if that one call fails, the setTimeout will not scroll them down in the retry as it's not passing in the flag. Might explain why the sticky scroll sometimes does not work after switching

=> I've seen this because I was thinking of ways to move getNewMessages() into the store, but first need to handle the "scroll to bottom" logic. This could be achieved by having a new EventBus event "receivedNewMessages" when more than 0 messages was loaded. The handler could then scroll if the condition for "followInNewMessages" is met.
(a watcher on the length of the messages store list might work as well)