Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Soft failed events cause extremities to build up #5269

Closed
erikjohnston opened this issue May 28, 2019 · 1 comment
Closed

Soft failed events cause extremities to build up #5269

erikjohnston opened this issue May 28, 2019 · 1 comment
Assignees

Comments

@erikjohnston
Copy link
Member

erikjohnston commented May 28, 2019

This affects v0.99.5 and was introduced in #5146, though that was fixing otherwise broken behaviour.

Broadly, when we receive an event that we soft-fail we do not update the forward extremities with the new event nor remove events that it references. This ensures that the server does not point to the soft failed event when building new events.

However, if another server sends an event that references the soft failed event (typically the original server) that is not soft-failed, then we update the forward extremities table with the new event but do not remove the original extremity referenced by the soft failed event.

The fix to this is to correctly delete the original extremity when the new non-soft-failed event is received.

@erikjohnston erikjohnston self-assigned this May 28, 2019
@erikjohnston
Copy link
Member Author

A query to find the the number of extremities whose parents have been soft failed is:

SELECT
	CASE WHEN internal_metadata IS NOT NULL THEN COALESCE(internal_metadata::json->>'soft_failed', 'false') ELSE '<not referenced>' END AS "Soft Failed",
	COUNT(*) AS "Count"
FROM event_forward_extremities AS f
LEFT JOIN event_edges
	ON prev_event_id = f.event_id
LEFT JOIN event_json
	ON event_edges.event_id = event_json.event_id
WHERE
	f.room_id = <room_id>
GROUP BY CASE WHEN internal_metadata IS NOT NULL THEN COALESCE(internal_metadata::json->>'soft_failed', 'false') ELSE '<not referenced>' END;

Though this double counts if extremities have multiple parents.

erikjohnston added a commit that referenced this issue May 28, 2019
When we receive a soft failed event we, correctly, *do not* update the
forward extremity table with the event. However, if we later receive an
event that references the soft failed event we then need to remove the
soft failed events prev events from the forward extremities table,
otherwise we just build up forward extremities.

Fixes #5269
erikjohnston added a commit that referenced this issue May 28, 2019
Due to #5269 we may have extremities in our DB that we shouldn't have,
so lets add a cleanup task such to remove those.
erikjohnston added a commit that referenced this issue May 29, 2019
When we receive a soft failed event we, correctly, *do not* update the
forward extremity table with the event. However, if we later receive an
event that references the soft failed event we then need to remove the
soft failed events prev events from the forward extremities table,
otherwise we just build up forward extremities.

Fixes #5269
erikjohnston added a commit that referenced this issue May 29, 2019
Due to #5269 we may have extremities in our DB that we shouldn't have,
so lets add a cleanup task such to remove those.
erikjohnston added a commit that referenced this issue May 30, 2019
Due to #5269 we may have extremities in our DB that we shouldn't have,
so lets add a cleanup task such to remove those.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant