From dad0c7dac286406b71c608658dd4a6c147bb5d08 Mon Sep 17 00:00:00 2001 From: Neil Alexander Date: Wed, 12 Jan 2022 17:29:55 +0000 Subject: [PATCH] Update 3618-simplify-federation-send.md --- proposals/3618-simplify-federation-send.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/proposals/3618-simplify-federation-send.md b/proposals/3618-simplify-federation-send.md index a9dbaa260..8bed8063f 100644 --- a/proposals/3618-simplify-federation-send.md +++ b/proposals/3618-simplify-federation-send.md @@ -31,9 +31,9 @@ that we return only one of two conditions: ## Benefits -A significant benefit is that the receiving homeserver no longer needs to block -the `/send` request in order to wait for the events to be processed for their error -results. +A significant benefit is that the receiving homeserver no longer needs to block the +the `/send` request in order to wait for the events to be processed for their `PDU Processing +Result`s. Given that it is possible for a transaction to contain events from multiple rooms, or EDUs for unrelated purposes, it is bad that a single busy room can lengthen the amount of @@ -44,10 +44,10 @@ per the spec: > The sending server must wait and retry for a 200 OK response before sending a > transaction with a different txnId to the receiving server. -With this proposal, the receiving server needing to block the `/send` response to wait for -`PDU Processing Result`s becomes optional rather than required. Receiving servers that do -not want to durably persist transactions before processing them can continue to perform all -work in-memory by continuing to block on `/send` as is done today. Additionally, a receiving +With this proposal, the receiving server no longer needs to wait for `PDU Processing Result`s +as this MSC does away with them. Receiving servers that do not want to durably persist transactions +before processing them can continue to perform all work in-memory by continuing to block the `/send` +request until all processing is completed, as may be done today. Additionally, a receiving server that is receiving too many transactions from a remote homeserver may wish to block for an arbitrary period of time for rate-limiting purposes, but this is an implementation specific detail and not strictly required. @@ -58,4 +58,6 @@ observing 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. +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)). +Conduit does the same and treats the response as an empty list if it is not present. Dendrite +ignores the response body altogether.