Replies to thread fallbacks are not shown in thread summary

[HarHarLinks]

Steps to reproduce

user A has labs threads on
user B has labs threads off

1. B sends a message
2. A starts thread on the message
3. B sees it as a reply due to fallback and replies to the reply
4. A sees the reply in the thread, but the thread preview button in the timeline does not update to show it

Outcome

What did you expect?

consistent preview button thing (that's totally the technical term) and thread timeline

What happened instead?

inconsistent

Operating system

arch

Application version

Element Nightly version: 2021112501 Olm version: 3.2.3

How did you install the app?

aur

Homeserver

No response

Will you send logs?

No

[germain-gg]

Duplicate of #19723 I believe

[HarHarLinks]

Duplicate of #19723 I believe

no, the thread summary (which is the button that appears in the timeline where a thread starts?) does update when you hover your mouse over it normally. in this specific case, it doesn't.

[germain-gg]

I've just tested this and it seems to behave pretty much the same as #19723

[HarHarLinks]

I believe step 3 above was actually sent from android which might not even have reply fallbacks and see it as just a regular event.
Its source is structured like this:

{
  "content": {
    "algorithm": "m.megolm.v1.aes-sha2",
    "ciphertext": "hush-hush",
    "device_id": "some android",
    "m.relates_to": {
      "m.in_reply_to": {
        "event_id": "$123456789abcdef"
      }
    },
    "sender_key": "redacted",
    "session_id": "redacted"
  },
  "event_id": "$fedcba987654321",
  "origin_server_ts": 1637934660709,
  "room_id": "!my:room",
  "sender": "@B:example.org",
  "type": "m.room.encrypted",
  "unsigned": {
    "age": 276262606
  },
  "user_id": "@B:example.org",
  "age": 276262606
}

The missing parts seem to be

"m.relates_to": {
      "event_id": "$123456789abcdef",
      "rel_type": "io.element.thread"
    }

Maybe desktop isn't supposed to have android's events fall back to threads? I would disagree however, it's every confusing if some kinds of replies do and others don't fall back to threads (something something ecosystem compatibility). I thought you just check an element that's replied to and if it's in a thread put it into there also.

[HarHarLinks]

This is another thing that happened while reproducing:

• Message 1 and 2: from element nightly with threads
• Message 3 from develop.element.io without threads
• Message 4 from element (schildichat) android 1.3.8

message 2 at the bottom is the actual message 2 from before, same event ID

[germain-gg]

Maybe desktop isn't supposed to have android's events fall back to threads? I would disagree however, it's every confusing if some kinds of replies do and others don't fall back to threads (something something ecosystem compatibility). I thought you just check an element that's replied to and if it's in a thread put it into there also.

I believe Android has not released the fallback just yet. So what you're experiencing is expected at the moment but not what we're aiming for for the first release.

[HarHarLinks]

Isn't the purpose of a fallback to work even when the other client does not support a fancy new feature?

I would normally consider this bad, but with the discrepancy of the summary and the thread view, it's quite horrible!

Link to that message/thread: https://matrix.to/#/!QQpfJfZvqxbCfeDgCj:matrix.org/$Z0JQM5FY6pofhlOB_Fg-obdyPO8lCBL7JDei9cVKecU?via=matrix.org&via=envs.net&via=kde.org

[germain-gg]

Oh that is definitely quite odd indeed! I have not experienced the discrepancy betweent the summary and the actual thread.
I'll investigate this one. I understood something slightly differently

[HarHarLinks]

you might want to re-open to track this

[HarHarLinks]

I just received a reply from android to a message I posted to a thread. It left me baffled with a notification indicator in the room list for a while. I looked from android and eventually found there was a message, but on desktop had to switch rooms and close and reopen the threads panel until it appeared in the thread (but still not the thread summary).

I also found that reply-chains are not going into threads at all, e.g.

1. Amy writes a message
2. Bob starts a thread using element web
3. Charlie replies to Bob's message using android. Charlie's reply is displayed in the thread on web, but not the thread summary as seen in the original issue.
4. Diana replies to Charlie's message using android. Diana's reply does not go into the thread at all.
5. etc

Again I urge you to re-open this issue, @gsouquet. Thanks for your work on threads.

[germain-gg]

I also found that reply-chains are not going into threads at all, e.g.

The android team has not yet released that. Support for this is coming

All of the concerns that you're raising here are already tracked and already will be tackled before the release of threads. It might not always be obvious with the issue names that this is included, but this is definitely part of the acceptance criteria of many issues I'm working on

[HarHarLinks]

The android team has not yet released that. Support for this is coming

again: this should work without any support by the sending client (i.e. android), since it is a fallback feature.

[germain-gg]

That's not the decision that we decided to take with MSC3440.
We can not do that fallback without slashing the reply feature in a thread. I'd recommend you go comment in the MSC if you think this should be handled differently