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