bug: thread root aggregated latest event missing sender field #2167

Open
opened 2026-08-22 14:43:47 +00:00 by ajbura · 4 comments

What is the bug?

m.thread relations added by server to the thread root unsigned content is missing required sender property.

Steps to reproduce

  1. send an event.
  2. send a thread reply
  3. refresh the app
  4. observe the root event unsigned content

Server name and version

26.7.3

Additional context

No response

### What is the bug? `m.thread` relations added by server to the thread root unsigned content is missing required `sender` property. ### Steps to reproduce 1. send an event. 2. send a thread reply 3. refresh the app 4. observe the root event unsigned content ### Server name and version 26.7.3 ### Additional context _No response_
Author

it looks like the content of event is assigned to the latest_event instead of assigning the event itself.

link to problem area:

relations.latest_event = Raw::from_json(event.content().to_owned());

it looks like the `content` of event is assigned to the `latest_event` instead of assigning the `event` itself. link to problem area: https://forgejo.ellis.link/continuwuation/continuwuity/src/commit/9491be928d6ded74e8a2750dc52b7f299b9fd446/src/service/rooms/threads/mod.rs#L93
Owner

Ah, this looks like a pain/problem because those functions are pre-continuwuity code and write the thread data directly to the database representation of the PDU. Might have to be fixed as a part of an (already needed) larger refactor, for historic messages at least

Ah, this looks like a pain/problem because those functions are pre-continuwuity code and write the thread data directly to the database representation of the PDU. Might have to be fixed as a part of an (already needed) larger refactor, for historic messages at least
Owner

I'm already working on refactoring how we handle unsigned data (and also backfilled events, but that's a separate thing), ftr. Would that perhaps be something I need to add to my list?

I'm already working on refactoring how we handle unsigned data (and also backfilled events, but that's a separate thing), ftr. Would that perhaps be something I need to add to my list?
Owner

Yep. Ideally this would be handed by the event relation table we have, which would reduce data duplication.

Yep. Ideally this would be handed by the event relation table we have, which would reduce data duplication.
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
continuwuation/continuwuity#2167
No description provided.