Accepting a room invite does not reliably show history since the invite was sent.

[ara4n]

Steps to reproduce

1. Invite someone to a room
2. Talk in the room lots
3. They finally accept the invite
4. They don’t get shown scrollback (although they can see prior content in reply previews)

Outcome

What did you expect?

history sent since they were invited should be visible.

What happened instead?

flakiness

Your phone model

No response

Operating system version

No response

Application version

427

Homeserver

No response

Will you send logs?

No

[ara4n]

sometimes the history is visible the first time you view the room, but then vanishes or vanishes the 2nd time you view the room.

[giomfo]

@stefanceriu Hi, do you know if this issue is observed on EX-Android too? Don't you think it is a Rust sdk issue? What would be the complexity to fix it?

[stefanceriu]

It's already marked as X-Needs-Rust but I wouldn't know where to start estimating it, we need Rust team support for that.

[stefanceriu]

I rested this today and am no longer able to reproduce it. Sent over 100 messages before accepting the invite and they all were rendered properly

• backpagination worked
• re-entering the room or restarting the app didn't change anything

[ara4n]

I just saw this happen first hand on Amandine's account (albeit on build 628)

[ara4n]

i would assume this is some nasty race on when you subscribe to the room v. when you backpaginate the room or something

[ara4n]

this is a dup of https://github.com/element-hq/element-x-ios/issues/1240

[ara4n]

Hearing reports of this on 1.6.11 (June 18th release):

[bnjbvr]

I think this is related to https://github.com/matrix-org/matrix-rust-sdk/issues/3622.

[jmartinesp]

It does seem related, in a version without the fix for https://github.com/matrix-org/matrix-rust-sdk/issues/3622 I was able to reproduce something similar by creating the room in EXA, then inviting the user and immediately killing the internet connection of my device, accepting the invite in another client and then restoring internet connection in my device so the messages are sent.

I got this on EW:

Screenshot

And this on EXA in the other client:

Screenshot

EW displays the first 3 messages sent while the app was offline as UTDs, because of the linked error in the Rust SDK, and the 2 new ones are fine (although the replied to messages are UTDs too).

EXA displayed the 5 messages as UTDs the first time I opened the room, then only the new 3 ones, which seems quite similar to what is discussed here (the first 2 UTDs are removed from the TL forever).

However I haven't been able to reproduce it again 🫤 .

[manuroe]

I moved the occurence to Uncommon as the bug happens less often than before.

[ara4n]

i got this badly a few days ago. from memory:

• Accepted invite
• Could see history
• Invited someone else to the room
• Reopened the room
• History no longer visible.

see rageshake.

[ara4n]

have marked O-Occasional as in practice i think i've seen this on almost every invite i've received (but presumably others don't)?

[mxandreas]

Just did test this on latest nightly Android (inviting) > iOS (accepting). Could see all the 15 messages after accepting the inviting.

[stefanceriu]

Was able to reproduce this just now Web to iOS:

• new room
• invite first user
• send 50 messages
• first user accepts and sees all messages
• invite second user
• see timeline get limited to the last 20ish events showing this is the begining of room at the top
• happens every time a new user is invited
• closing and reopening the room doesn't change anything
• closing and reopening the app gives back full history

[ara4n]

Right. that sounds like the one. I also got it just now on a fresh login; i viewed a room which was fine at first, went back to room list, went in again, and all the history before the most recent join suddenly vanished.

[pixlwave]

Turns out this has nothing to do with invites and occurs on any room that has more than a single sync chunk's worth of messages and that you've scrolled all the way back to the start.

It can be reproduced by scrolling back to the start in any room, closing it and then opening it again. I've tracked it down to here where after we've reached the start of a room, initial will always be Idle { hit_start_of_timeline: true } which tells the app to show the start timeline item and not to paginate any more.

I think this is made worse by the timeline resets the SSS is doing more frequently, but it still happens without seeing a reset on the screen too (I haven't checked with a SS proxy).

[bnjbvr]

Thanks for that last comment @pixlwave, that highlighted the issue to me, will write a patch.