Skip to content

Instantly share code, notes, and snippets.

@richvdh
Last active May 9, 2019 21:09
Show Gist options
  • Save richvdh/2e29267044232df055a5aa337f0dd3f6 to your computer and use it in GitHub Desktop.
Save richvdh/2e29267044232df055a5aa337f0dd3f6 to your computer and use it in GitHub Desktop.

I've now seen several people point at synapse#5133 and say "federation is broken in synapse 0.99.2".

I would never want to discourage people from upgrading, since each release usually comes with a raft of general bug fixes and performance improvements. However, there seems to be a lot of confusion around this point, so I'd like to clear some things up.

The confusion appears to arise from Synapse's implementation of the /_matrix/federation/v1/send/{txnId} federation REST endpoint. Up to, and including, Synapse 0.99.2, this was implemented in a way that was not compliant with the Matrix spec - in particular, it added a trailing slash to the URI (thus making it /_matrix/federation/v1/send/{txnId}/) to outbound requests, and required that trailing slash on inbound requests.

This was fixed in Synapse 0.99.3 by:

  1. Accepting inbound requests without the trailing slash (as specfied) as well as those with the trailing slash (as implemented by Synapse 0.99.2). (#4793).
  2. For outbound requests, initially making outbound requests without the trailing slash (as specified), and then, if that failed, retrying with the trailing slash (as required by Synapse 0.99.2). (#4840).

Please note that we made particular effort here to ensure that 0.99.2 and 0.99.3 are compatible.

However, one effect that is apparent is potentially large numbers of log lines like:

It's important to note that these log lines, while annoyingly noisy, are harmless from the operational point of view, because the failed request will be immediately retried with the addition of the trailing slash.

Now, the backwards-compatibility hacks aren't going anywhere in Synapse any time soon. At some point, we can hope for an ecosystem where we have other working homeserver implementations, and other implementations probably won't support the non-spec-compliant interface, so Synapse 0.99.2 and earlier will be incompatible with such implementations - but, for better or worse, we aren't there yet, so I don't think it's a cause for panic just yet [1].

In the meantime, this means that you're unlikely to see any practical problems with Synapse 0.99.2, apart from decreased performance due to the extra incoming HTTP requests.

In any case, the whole thing is irrelevant to #5133, which is about whether we can blacklist more agressively non-responsive homeservers. We are obviously not going to treat Synapse 0.99.2 as "non-responsive".

[1] At some point I guess that distributions like Debian which attempt to provide support for years rather than months are going to have to look at either updating Synapse or backporting the relevant updates, but again: let's not panic just yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment