Description
The event_thread_relation background update is fairly heavy and only looks for the unstable io.element.thread relation. We will need to essentially re-run this when MSC3440 is stabilized to search for m.thread relations instead.
It seems a better way to do this would be to store unknown relation types into the database (and potentially filter them on fetch) so that we do not need to crawl all events in the future when more relation types are added. If a future relation has additional data which must be processed, similar to the key field of m.annotation, then this would allow easily re-processing only the events with that relation.
Note that this was previously discussed at #11088 (comment) but rejected. This is being reconsidered in light of #11375 and other problems with running this background update.
The overall plan for how to accomplish this would be:
- Replace the current background update with a no-op, this allows any servers which have not finished it to give up.
- Write a new background update that does something similar, but pulls in any relation type.
- Rework the code in
_handle_event_relationsto save any relation of new events (instead of only known relations). - (Optionally) Modify places where we fetch relations to limit to only "known" relations.
This also has the benefit of allowing for easier experimentation with unknown relations. Synapse would (somewhat obviously) not include those in bundled relations since the format of those is custom per relation type.