MSC3934: Bulk push rules change endpoint

[turt2live]

Rendered

[turt2live]

to clarify: for this and the endpoint below, the server treats it as a transaction: if one of the rules fails to update (due to not existing, DB error, etc) then all rules fail to update (a rollback).

[Johennes]

I think this is a great improvement over what the spec allows today. However, one slight shortcoming is that clients would still need multiple calls if they wanted to update rules of different kinds. I wonder if that's a use case we should seek to support? E.g. I suppose we could move the kind parameter into the body of the request?

[Johennes]

Along the same train of thought, this proposal also doesn't allow changing actions and enabled simultaneously. In both cases the client would be left with the multi-failure mode we're trying to fix. This almost makes me wonder if we'd need a PUT /_matrix/client/v1/pushrules_bulk?

[turt2live]

I'm somewhat concerned about giving clients too much ability to cause performance issues on the server-side with large bulk endpoints (each push rules change triggers a sync loop poke). In theory, the client can isolate the actions and enabled calls safely, and encouraging them to do so would be a good thing imo.

Supporting bulk changes across different kinds is an interesting question though: it implies that one or more push rules might be at the wrong level and need redefining or reconsidering. I'm very interested in this sort of usecase :)

[Johennes]

I'm somewhat concerned about giving clients too much ability to cause performance issues on the server-side with large bulk endpoints (each push rules change triggers a sync loop poke).

Good point, yes. Could the /sync triggers be batched up on the server-side so that you only trigger a single time for any bulk request?

the client can isolate the actions and enabled calls safely, and encouraging them to do so would be a good thing imo

The Element iOS app uses an interesting logic here. When you toggle any of the global notification settings on or off, it issues two PUTs. One to /enable to ensure that the rule is actually on and one to /actions to toggle between notify and dont_notify. I'm not sure if other clients behave similarly but in this case there are two requests tied to a single UI control so isolating them would probably be tricky?

Supporting bulk changes across different kinds is an interesting question though: it implies that one or more push rules might be at the wrong level and need redefining or reconsidering. I'm very interested in this sort of usecase :)

Yeah, when thinking through it again, I'm actually failing to come up with a reasonable example. You're probably right that this should normally be taken care of by the priority hierarchy of the different rule kinds.

[turt2live]

It would only be a single sync trigger, but that's still a large trigger to happen: we're actively avoiding APIs that allow for arbitrarily large requests/responses, and an endpoint which is "too bulk" would ultimately cause excess data to be transmitted.

As for Element iOS: this sounds like a bug in the client. The client should have a cached copy of the push rules to be able to make decisions on, and the UI control would still be able to represent a failed state: setting actions on a disabled rule prepares it for when it can be enabled, meaning the client can use the enabled/disabled state to determine if something went wrong. A suggested approach would be to set the actions first (where if it fails the client has no-oped the user's request), then enable the rules. If the enable step fails, the UI control can show that easily, allowing the user to try again. With caching, the client can also determine if it needs to change the actions/enabled state of each individual rule it plans to affect.

[Johennes]

It would only be a single sync trigger, but that's still a large trigger to happen: we're actively avoiding APIs that allow for arbitrarily large requests/responses, and an endpoint which is "too bulk" would ultimately cause excess data to be transmitted.

Ah, got it. That makes sense. 👍

setting actions on a disabled rule prepares it for when it can be enabled, meaning the client can use the enabled/disabled state to determine if something went wrong

That's a great point! @alfogrillo we should make sure that the PUTs are issued this way around on Element iOS.

[alfogrillo]

I can confirm that:

• Element Desktop: runs actions, then enabled on completion
• Element iOS: runs actions and enabled concurrently 😅

@Johennes is it ok for you if I add a new ticket in our backlog for this (it's also worth checking Android)?

[Johennes]

Yes, should hopefully be an easy fix.