matrix-js-sdk

fa1bd59f - MSC4140: read the delayed events capability and recognise `M_DELAY_TOO_LARGE` (#5564)

MSC4140: read the delayed events capability and recognise `M_DELAY_TOO_LARGE` (#5564) * Add the MSC4140 delayed events capability to the Capabilities type Signed-off-by: Paul Chobert <paul@chobert.fr> * Clamp the MatrixRTC delayed leave delay to the server maximum Recognise M_DELAY_TOO_LARGE and ORG.MATRIX.MSC4140_DELAY_TOO_LARGE, which carry no limit, and read the limit from the delayed events capability. The cached capabilities are applied before the first attempt, and delayed events are skipped when the capability says they are disabled. When the capabilities are not reachable (widget mode), halve the delay until the server accepts it or it drops below the restart interval. Signed-off-by: Paul Chobert <paul@chobert.fr> * Do not treat an absent delayed events capability as disabled Synapse before 1.157.0 supports delayed events without advertising the capability, and rejects a too large delay with the legacy M_MAX_DELAY_EXCEEDED error. Only an explicit 0 disables delayed events. Signed-off-by: Paul Chobert <paul@chobert.fr> * Add TODOs to drop the support for Synapse before 1.157.0 Signed-off-by: Paul Chobert <paul@chobert.fr> * Remove a redundant comment in the MembershipManager test Signed-off-by: Paul Chobert <paul@chobert.fr> * Update src/matrixrtc/MembershipManager.ts Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org> * Refetch the capabilities when the server rejects the delay If the capabilities were cached, the delay was already clamped to them before sending, so a M_DELAY_TOO_LARGE means the cached values are missing or out of date. getCapabilities() would return the same cache, so use fetchCapabilities() to get the current limit. Signed-off-by: Paul Chobert <paul@chobert.fr> * Make both delayed events capability fields required MSC4542 clarified MSC4140: the server must enforce both limits, so max_delay_ms and max_scheduled are always present in the capability. Signed-off-by: Paul Chobert <paul@chobert.fr> * Add TODOs to read the delayed events capability through the widget API Signed-off-by: Paul Chobert <paul@chobert.fr> * Only remember lasting failures to fetch the capabilities Stop fetching the capabilities only when the server refused the request with a client error, as in widget mode where the request has no access token. Network errors, rate limits and server errors are temporary, so fetch again on the next rejection. Reset the flag once a delayed event is accepted, like the rate limit retry counters. Signed-off-by: Paul Chobert <paul@chobert.fr> * Fetch the capabilities again after an unreachable period Instead of a flag, remember until when the capabilities are considered unreachable, so a lasting failure is retried after 5 minutes even if no delayed event gets accepted in the meantime. Signed-off-by: Paul Chobert <paul@chobert.fr> * Treat an absent delayed events capability as disabled Signed-off-by: Paul Chobert <paul@chobert.fr> * Fix tests --------- Signed-off-by: Paul Chobert <paul@chobert.fr> Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>