element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients
75 stars 12 forks source link

Redacting thread event makes subsequent messages (replies) dissappear #2036

Open rda0 opened 1 year ago

rda0 commented 1 year ago

Steps to reproduce

  1. write a message
  2. create a 'reply in thread' reply
  3. redact event from 2) (tread reply)
  4. create normal timeline reply to the redacted event from 2)

Outcome

client 1

  1. Message deleted by xyz notice for event 2) is missing
  2. Normal timeline reply (event 4) is missing thread_bug_01 Sometimes there is a box 1 reply (as shown above), sometimes not.

The debug console shows:

EventTimelineSet:canContain event encountered which cannot be added to any timeline roomId=!aTvivYGclTcDSRxPjp:phys.ethz.ch eventId=$FAtrE-Bsx17sFXCfM2Cv0Db-Fwu18VdngNPBE9DukHU threadId=undefined [bundle.js:2:3191826](https://element.phys.ethz.ch/bundles/9080b7a61d57e094dbd7/bundle.js)
EventTimelineSet.addEventToTimeline: Ignoring event=$FAtrE-Bsx17sFXCfM2Cv0Db-Fwu18VdngNPBE9DukHU that does not belong in timeline=!aTvivYGclTcDSRxPjp:phys.ethz.ch:2023-09-06T09:03:01.627Z timelineSet(threadId=undefined)

client 2

Here is a screenshot of another client instance that does not show this box but shows the missing event from 4): thread_bug_02

client 1

After clear cache + reload, the client shows it correctly, as I would expect: thread_bug_03

Operating system

Linux Ubuntu 22.04

Browser information

not browser specific (tested in Desktop App + Firefox)

URL for webapp

element.phys.ethz.ch

Application version

Element version: 1.11.40 Olm version: 3.2.14

Homeserver

phys.ethz.ch

Will you send logs?

Yes

t3chguy commented 1 year ago

Sorry it is unclear what you mean by

create normal timeline reply to the redacted event from 2)

How are you replying to a redacted threaded event in the main timeline?

A video of the reproduction would be appreciated.,

rda0 commented 1 year ago

How are you replying to a redacted threaded event in the main timeline?

This is done by another client (a bot). Here is the event source:

{
  "content": {
    "body": "...",
    "format": "org.matrix.custom.html",
    "formatted_body": "...",
    "m.relates_to": {
      "m.in_reply_to": {
        "event_id": "$MI5F8zu1KGgu0JKjTxr7hLOWz-FNt4med-0XF1bpK9U"
      }
    },
    "msgtype": "m.notice"
  },
  "origin_server_ts": 1693999872803,
  "sender": "@antithread:phys.ethz.ch",
  "type": "m.room.message",
  "unsigned": {
    "age": 450
  },
  "event_id": "$QAU4hhJDerPYLdiyH1pRwiNEj31tb0DHrbdLiCZz5sI",
  "room_id": "!aTvivYGclTcDSRxPjp:phys.ethz.ch"
}
t3chguy commented 1 year ago

I think the issue is one where when the event is redacted it loses its thread relation so a reply to the redacted event lives in limbo depending on what state the client has. This is an undefined space which the spec doesn't seem to cover.

rda0 commented 1 year ago

I think the issue is one where when the event is redacted it loses its thread relation so a reply to the redacted event lives in limbo depending on what state the client has. This is an undefined space which the spec doesn't seem to cover.

OK, I am not very up to date with threads spec changes and I did not know if what was happening here is even "supported". But at least there is some inconsistent behavior, which appears to be fixed by a cache clear.

clokep commented 1 year ago

Related to MSC3389.