From 7f4b1cbc72ebbeabcb2f08c6032fa95105cba150 Mon Sep 17 00:00:00 2001 From: Neil Alexander Date: Tue, 4 Jan 2022 17:09:25 +0000 Subject: [PATCH] Wrapping --- proposals/3618-simplify-federation-send.md | 39 ++++++++++++++++------ 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/proposals/3618-simplify-federation-send.md b/proposals/3618-simplify-federation-send.md index e10075b12..3d0d782fd 100644 --- a/proposals/3618-simplify-federation-send.md +++ b/proposals/3618-simplify-federation-send.md @@ -2,25 +2,44 @@ ## Overview -Currently we specify that the federation `/send` endpoint returns a body of `pdus: { string: PDU Processing Result}`. In theory a homeserver can return information here on an event-by-event basis as to whether there was a problem processing events in the transaction or not. - -However, this does not really make much difference in practice — soft-fails are silent and rejected events may be too – and server implementations do not "cherry-pick" which events in a transaction to retry later. Since the presence of a `txnId` in the request implies that we should consider a transaction to be idempotent for a given `txnId`, we should therefore either accept that the entire transaction was accepted successfully by the remote side or we retry the entire transaction later. - -The worst case is that the homeserver is not able to process the transaction at all for some reason, i.e. due to the database being down or similar, in which case the server really should just return a HTTP 500 status code and this signals to the sender to retry later. +Currently we specify that the federation `/send` endpoint returns a body of +`pdus: { string: PDU Processing Result}`. In theory a homeserver can return +information here on an event-by-event basis as to whether there was a problem +processing events in the transaction or not. + +However, this does not really make much difference in practice — soft-fails +are silent and rejected events may be too – and server implementations do not +"cherry-pick" which events in a transaction to retry later. Since the presence +of a `txnId` in the request implies that we should consider a transaction to be +idempotent for a given `txnId`, we should therefore either accept that the +entire transaction was accepted successfully by the remote side or we should +retry the entire transaction. + +The worst case is that the homeserver is not able to process the transaction at +all for some reason, i.e. due to the database being down or similar, in which +case the server really should just return a HTTP 500 status code and this +signals to the sender to retry later. ## Proposal -This MSC proposes that we remove the `pdus` section from the response body, so that we return only one of two conditions: +This MSC proposes that we remove the `pdus` section from the response body, so +that we return only one of two conditions: * A HTTP 200 with a `{}` body to signal that the transaction was accepted; -* A HTTP 500 to signal that there was a problem with the transaction and to retry sending later. +* A HTTP 500 to signal that there was a problem with the transaction and to retry + sending later. ## Benefits -A significant benefit is that homeserver implementations no longer need to block the `/send` request in order to wait for the events to be processed for their error results. This can potentially remove head-of-line blocking from `/send` altogether if homeservers can durably queue the incoming events before returning. +A significant benefit is that homeserver implementations no longer need to block +the `/send` request in order to wait for the events to be processed for their error +results. This can potentially remove head-of-line blocking from `/send` altogether +if homeservers can durably queue the incoming events before returning. -Another benefit is that homeservers no longer need to parse the response body at all and can instead just determine whether the transaction was accepted successfully by the HTTP status code. +Another benefit is that homeservers no longer need to parse the response body at +all and can instead just determine whether the transaction was accepted successfully +by the HTTP status code. ## Potential issues -Synapse appears to use the `"pdus"` key for logging (see [here](https://github.com/matrix-org/synapse/blob/b38bdae3a2e5b7cfe862580368b996b8d7dfa50f/synapse/federation/sender/transaction_manager.py#L160)). Dendrite, however, ignores the response body altogether. \ No newline at end of file +Synapse appears to use the `"pdus"` key for logging (see [here](https://github.com/matrix-org/synapse/blob/b38bdae3a2e5b7cfe862580368b996b8d7dfa50f/synapse/federation/sender/transaction_manager.py#L160)). Dendrite, however, ignores the response body altogether.