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

Sync failing with 404 M_NOT_FOUND when the user is invited to a room with an unknown version #10525

Closed
t3chguy opened this issue Aug 4, 2021 · 5 comments · Fixed by #10644
Closed
Labels
S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@t3chguy
Copy link
Member

t3chguy commented Aug 4, 2021

Description

As per the title; tried logging into my matrix.org test account and /sync responded with a 404 over and over again

image

Version information

  • Homeserver: matrix.org

I believe the account was @webdevguru_test17:matrix.org in case that helps with log spelunking

It might be because the user was in an msc3083 unstable room the server dropped support for. 🔥

@babolivier
Copy link
Contributor

This error is referring to an event sent in room !KQakPoXjBfiHdvvssg:matrix.org which indeed has the version org.matrix.msc3083. The event ($h0z7A514gZv7MmOt7y6Cck7Af2PcgDZDsmoEs8I5mC0) is @webdevguru_test22:matrix.org inviting @webdevguru_test17:matrix.org into the room.

@babolivier
Copy link
Contributor

So what's happening here is:

  • the sync handler loads the list of room memberships for this user
  • it sees that the user is invited to the room
  • it tries to get the invite event for this room using get_events, which eventually calls _get_events_from_db
  • _get_events_from_db retrieves the event and checks the room version against known ones
  • the room version isn't known so it ignores it
  • _get_events_from_db returns no event, so get_events raises a 404 error

The check on the room version is here:

room_version = KNOWN_ROOM_VERSIONS.get(room_version_id)
if not room_version:
logger.warning(
"Event %s in room %s has unknown room version %s",
event_id,
d["room_id"],
room_version_id,
)
continue
if room_version.event_format != format_version:
logger.error(
"Event %s in room %s with version %s has wrong format: "
"expected %s, was %s",
event_id,
d["room_id"],
room_version_id,
room_version.event_format,
format_version,
)
continue

@babolivier babolivier changed the title /sync can fail with 404 M_NOT_FOUND Sync failing with 404 M_NOT_FOUND when the user is invited to a room with an unknown version Aug 4, 2021
@callahad callahad added T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. S-Critical Blocks development, potential data loss, more than 25% of users possibly affected, no workarounds. labels Aug 4, 2021
@callahad
Copy link
Contributor

callahad commented Aug 4, 2021

Bumping to S-Critical as I'm assuming it blocks development work for @t3chguy (please let us know if it doesn't).

Bricking unstable rooms is one thing, but bricking accounts that have interacted with unstable rooms is quite another, and something I'm keen to see resolved prior to 1.40 going out.

@t3chguy
Copy link
Member Author

t3chguy commented Aug 4, 2021

It isn't blocking my development work, it is one of my ~30 test accounts, just happens to be the one my FF instance defaulted to and confused me why sync was returning 404.

Though if someone created such an unstable room (which Element Android release edition allowed you to do via UI) on their primary account then it'd be S-Critical for them

@clokep
Copy link
Member

clokep commented Aug 4, 2021

Just to define the impact I believe this will only cause an issue if you have an outstanding invite to an unknown room version, not users who have joined an unknown room version (see #7083).

Just to ensure we're all discussing the same thing:

  • "unstable" is a room version that Synapse knows about but is not stable, according to the spec.
  • "unknown" or "unsupported" is a room version which Synapse does not know about (and does not know how to interact with).
  • "experimental" is generally a synonym for "unstable" but if the spec ever made a stable room version unstable than they would differ ("experimental" would then mean unspecced, e.g. from an MSC or something).

@callahad callahad added S-Major Major functionality / product severely impaired, no satisfactory workaround. and removed S-Critical Blocks development, potential data loss, more than 25% of users possibly affected, no workarounds. labels Aug 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants