MSC4140: Cancellable delayed events - #4140
Conversation
0eb1abc to
8bf6db7
Compare
turt2live
changed the title
turt2live
added
proposal
c82adf7 to
54fff99
Compare
95c855f to
f3bf66d
Compare
96409b1 to
412464a
Compare
412464a to
1140ce9
Compare
Instead just say more clearly that the error returned is the same as what would have been returned for a non-delayed event request
Network errors on the endpoint would cause responses to be lost if they were to be discarded by the server
| [capability](https://spec.matrix.org/v1.19/client-server-api/#capabilities-negotiation) named `m.delayed_events`, via | ||
| the values of non-negative integer valued fields named `max_delay_ms` and `max_scheduled` respectively. | ||
| For any of these limits enforced by the server, its representative field MUST be present in the capability. | ||
| If the server doesn't enforce one of these limits, its representative field MUST be absent from the capability. |
There was a problem hiding this comment.
This framing does mean it's impossible for a server to say that delayed events are disabled. I'm not sure that is something we want to support, but equally feels odd. I'm not sure if it's worth doing anything about it though
There was a problem hiding this comment.
It can communicate disabled delayed events by responding with:
{
"capabilities": {
"m.delayed_events": {
"max_delay_ms": 0,
"max_scheduled": 0
}
}
}Even including only one of the max_ fields would be sufficient, as it's enough for either one of them to be 0 to mean that delayed events are disabled.
Does that cover your concern?
There was a problem hiding this comment.
Mmm, true I suppose. Though if we want clients to consider 0 to mean disabled then that's something we should be specific. While technically a limit of 0 is the same, it needs to be handled specially by clients (i.e. this operation will never work no longer how long we wait).
OTOH I'm not sure if we want to allow delayed events to be disabled by the server? I guess that is the fundamental question, and we should either explicitly allow or deny 0 as the limit.
(This is a very low severity thing)
There was a problem hiding this comment.
While technically a limit of 0 is the same, it needs to be handled specially by clients (i.e. this operation will never work no longer how long we wait).
Aha, this is what that "special case" I was banging on about was for. It landed as ec7cbfd.
OTOH I'm not sure if we want to allow delayed events to be disabled by the server?
IMO there's no harm to allow disabling it, especially if server configs already allow you to constrain it (why not allow constraining it all the way to 0?).
As another point, this section should also specify what clients should assume if the m.delayed_events capability is absent entirely (not just its fields).
af63014 does so, and also explicitly specifies what 0 limits mean.
There was a problem hiding this comment.
I suppose managing delayed events will cause some amount of load on the server. I suppose it's low but technically allowing an admin to disable it seems reasonable to me.
Even if we don't allow 0. A value of 1ms would still mean the feature is effectively disabled from a client's perspective.
Evaluate at both schedule & send time Co-authored-by: Erik Johnston <erik@matrix.org>
|
@mscbot resolve open comment threads |
for the sake of consistency
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
So I've gone through the whole thing (and a bunch of the old threads) and it makes sense - it's an alternative approach to my proposal at #3277 but there's a meaningful difference between asking your local HS to maybe send an event in future... versus asking your local HS to send an event right now, which servers should only reveal to their clients in future. I've approved it for FCP, but with one minor proviso: i really tripped over the "Delegating scheduled delayed events" section in Alternatives... because it's listed as an alternative (having previously been part of the main proposal), and yet MatrixRTC explicitly depends on delegated delayed events to function sensibly, by letting SFUs explicitly trigger delayed leave events when users leave a call. Now, it turns out that the way that works is that MSC4195 (LiveKit transport for MatrixRTC) specifies how a homeserver can cancel MSC4140 delayed events on behalf of the LiveKit SFU if the SFU knows that a user has dropped (the whole
It also feels weird that the MatrixRTC delegation approach has ended up as livekit-specific in the LK transport MSC, when there's nothing livekit specific about it? However, that's more a point for MSC4195. |
I have applied this in https://github.com/matrix-org/matrix-spec-proposals/pull/4140/changes#r3922947293. |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
|
Slightly belatedly, I'm going to open a concern to track a resolution to @jevolk's comment. (per the process: "a member of the Spec Core Team can raise a concern and block FCP from completing. This will not reset or pause the 5 day FCP timer, but FCP will not conclude until all concerns have been resolved") We're all going to pretend that I did this an hour ago. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
| - `delayed_since_ts` - Required. The timestamp (as Unix time in milliseconds) when the delayed event was scheduled or | ||
| last restarted. | ||
| - `content` - Required. The content of the delayed event. | ||
| This is the body of the original `PUT` request, not a preview of the full event after sending. |
There was a problem hiding this comment.
There was a problem hiding this comment.
I suppose what is meant here is the content object from the body of the original PUT request. Anything else would be fairly nonsensical. We should replace this with e.g.
This is the
contentproperty from the body of the originalPUTrequest, not a preview of the full event after sending.
There was a problem hiding this comment.
@turt2live can we still apply this clarification?
There was a problem hiding this comment.
Sure - a dedicated PR would be best.
| } | ||
| ``` | ||
|
|
||
| If the capability is absent, clients SHOULD assume that delayed events are disabled / not supported by the server, |
There was a problem hiding this comment.
Line 132 lets a capable server that doesn't enforce limits omit the capability itself.
Line 147 tells the client that absence means disabled.
The feature is not discovered.
| To mitigate the risk of users flooding the delayed events database, homeservers MUST impose limits on the number and | ||
| timeout duration of scheduled delayed events. The exact limits are left as an implementation detail. |
There was a problem hiding this comment.
Tip
- MAY enforce a maximum delay.
Warning
- SHOULD enforce a maximum scheduled count.
matrix-spec-proposals/proposals/4140-delayed-events-futures.md
Lines 99 to 102 in 1363dd1
Caution
- MUST enforce a maximum delay and maximum scheduled count !
matrix-spec-proposals/proposals/4140-delayed-events-futures.md
Lines 615 to 616 in 1363dd1
Warning
- SHOULD enforce a maximum scheduled count.
matrix-spec-proposals/proposals/4140-delayed-events-futures.md
Lines 629 to 630 in 1363dd1
|
|
||
| If the target delayed event is already finalised with an outcome that conflicts with the `action`, i.e. | ||
| if the `action` is `send` or `restart` and the delayed event has already been cancelled, | ||
| or if the `action` is `cancel` and the delayed event has already been sent, |
There was a problem hiding this comment.
| or if the `action` is `cancel` and the delayed event has already been sent, | |
| or if the `action` is `cancel` or `restart` and the delayed event has already been sent, |
The intent looks settled already: #4140 (comment) proposed 409 for restart on a sent or cancelled event, and 1e18fa2 ("Return 409 Conflict on any conflicting action") implemented it but listed only cancel for the sent case, so this reads as a transcription slip rather than a decision.
Line 204 gives send on a sent event a 200. Line 210 gives cancel on a sent event a 409. restart on a sent event is in neither list, and both lists are introduced with "i.e.", so it has no defined response.
matrix-spec-proposals/proposals/4140-delayed-events-futures.md
Lines 202 to 211 in 1363dd1
A periodic restart that lands after the timer, or another client's send, has already sent the event. 404 does not fit, which leaves each server to pick between 200 and 409, and the client reacts differently to each. matrix-js-sdk's membership manager recovers from a failed restart only on M_NOT_FOUND; a 409 falls through to a throw, and a 200 tells it the timer was reset after its membership is already gone.
| The homeserver MUST NOT send the event before the scheduled time, and | ||
| MAY send it up to 30 seconds after the scheduled send time. |
There was a problem hiding this comment.
| The homeserver MUST NOT send the event before the scheduled time, and | |
| MAY send it up to 30 seconds after the scheduled send time. | |
| The homeserver MUST NOT send the event before the scheduled time, except in response to the | |
| [`send` action](#managing-scheduled-delayed-events), and MAY send it up to 30 seconds after the scheduled send time. |
Line 84 forbids sending before the scheduled time without exception. Line 173 defines send as sending the event "immediately instead of waiting for its scheduled send time", so a server cannot both keep the MUST NOT and support the action.
matrix-spec-proposals/proposals/4140-delayed-events-futures.md
Lines 84 to 85 in 1363dd1
The intent looks settled already: #4140 (comment), a thread about how late the timer may fire, where the promise being made was that the server never fires early on its own, and was committed in 1e527c3. The send action predates it by almost two years and keeps its own entry under Alternatives (line 551). Neither that thread nor the rewording in 062e649 mentions the action, so this reads as a wording slip rather than a decision.
20 participants
Rendered
This could also supersede MSC2228 (by making it possible to send a redaction with the
/sendendpoint. This is the case as mentioned here)Implementations
Known differences between current implementations and the proposal
/sendand/statewith a new query parameterdelayfor scheduling delayed events. The proposal has since switched to a dedicated endpointPUT /_matrix/client/v3/rooms/{roomId}/delayed_event/{eventType}/{txnId}where the delay is included in the request body./versionskey would be required to manage the migration from the previous unstable implementation.delay_id.Implementations in Element Call via the Widget API
These are only informational and shouldn't be relevant for the proposal process. The MSC doesn't depend on widgets and widgets are themselves not part of the spec.
SCT stuff:
MSC checklist
FCP tickyboxes
Designated reviewers: