bug: Really old databases may have corrupt extremity tracking #2259

New issue

Open

opened 2026-09-16 22:55:23 +00:00 by nex · 0 comments

nex commented

2026-09-16 22:55:23 +00:00

Owner

What is the bug?

From the conduwuit era (and very early versions of v0.5), it was possible for the extremity tracking table to be completely drained of forward extremities, which would corrupt the room. It would naturally heal when a new extremity was introduced, but for the duration of the extremityless track, legal local events could not be created, and after the gapfill update, nonlinear rooms will struggle to accept incoming events since get_missing_events will panic.

This is a highly illegal situation to be in - there is never a point in time where a Matrix room's graph has no extremities. Repairing this situation can be done broadly with a simple startup migration, but this is not something that should be done automatically (huge IO load), and I don't think it's something that should be in the mainline software since it's something that affects a fraction of a minority of deployments.

Steps to reproduce

There are none anymore (the relevant codepaths fail-safe before this situation can be encountered), I'm mainly opening this issue to link to it in a comment.

Server name and version

elisaado.com (26.8.1)

Additional context

No response

### What is the bug? From the conduwuit era (and very early versions of v0.5), it was possible for the extremity tracking table to be completely drained of forward extremities, which would corrupt the room. It would naturally heal when a new extremity was introduced, but for the duration of the extremityless track, legal local events could not be created, and after the gapfill update, nonlinear rooms will struggle to accept incoming events since get_missing_events will panic. This is a highly illegal situation to be in - there is never a point in time where a Matrix room's graph has no extremities. [Repairing this situation can be done broadly with a simple startup migration](https://forgejo.ellis.link/nex/continuwuity/commit/dcf704a386df16336ef73e0b34d687e59546ffec.patch), but this is not something that should be done automatically (huge IO load), and I don't think it's something that should be in the mainline software since it's something that affects a fraction of a minority of deployments. ### Steps to reproduce There are none anymore (the relevant codepaths fail-safe before this situation can be encountered), I'm mainly opening this issue to link to it in a comment. ### Server name and version elisaado.com (26.8.1) ### Additional context _No response_

nex added the

labels

2026-09-16 22:55:23 +00:00