fix: unfreeze notification_levels for PushRuleEvaluator#18103
fix: unfreeze notification_levels for PushRuleEvaluator#18103c-cal wants to merge 10 commits intoelement-hq:developfrom
Conversation
…RuleEvaluator, which can't handle immutabledict
|
|
| # _get_power_levels_and_sender_level in its call to get_user_power_level | ||
| # (even for room V10.) | ||
| notification_levels = power_levels.get("notifications", {}) | ||
| notification_levels = unfreeze(power_levels.get("notifications", {})) |
There was a problem hiding this comment.
I've just had a thought on how we could solve all of the cases in #18117 pretty elegantly without having to muck about in the downstream code,
Instead of calling unfreeze at the spot we're trying to use it here, we could unfreeze after we're done with the frozen event in the third party module callbacks (where we called freeze in the first place).
(unfreeze after we run all of the callbacks)
synapse/synapse/module_api/callbacks/third_party_event_rules_callbacks.py
Lines 291 to 316 in a0b7047
There was a problem hiding this comment.
In this case, unfreeze() must be applied to event._dict, but since it's a “private” attribute, it would probably be cleaner to do it directly from a dedicated method (eg: event.unfreeze). Is it reasonable to make such a method so easily accessible to callbacks?
There was a problem hiding this comment.
Is it reasonable to make such a method so easily accessible to callbacks?
This is a good point to consider. We could update the name to mark the method as internal (event._freeze()) which would discourage people from using it by convention.
Perhaps, we should just make a copy of the event that we freeze. Since we're taking the hit to freeze things anyway, it doesn't seem unreasonable to just make the event copy and freeze. We can use clone_event(...) and this prevents any possible tampering problems. If the clone is deep enough, we could avoid freezing altogether as we aren't really worried if they modify their own copy but I have a feeling we don't clone deep enough for the prev_event_ids and other lists etc.
There is FrozenEvent but it doesn't actually freeze the event all the time because it's "expensive" (see the USE_FROZEN_DICTS logic) so we can't use that.
… of PushRuleEvaluator, which can't handle immutabledict" This reverts commit b7a2e9f.
I was looking into the `USE_FROZEN_DICTS` option during the review of #18103 (comment) and noticed that there are several other server config options that aren't in the docs.
I got rid of the `SYNAPSE_USE_FROZEN_DICTS` environment variable because it will be overridden by the Synapse worker apps anyway and if we want to support `SYNAPSE_USE_FROZEN_DICTS`, it should be in `synapse/config/server.py`. It's also not documented so I'm assuming no one is using it anyway. Spawning from looking at the frozen dict stuff during the review of #18103 (comment)
|
@c-cal do you want to reopen that or should I take it over ? There are other side effects of having a frozen dict around, like pydantic validation failing if We are hitting that in production and would like to have a fix upstream. |
|
Github doesn't just allow me to reopen this one. But I can open an equivalent if the solution I proposed is suitable. I don't have time to investigate more about this. |
|
The solution is good, but I would like to add a test and a clearer message. If you don't mind I can keep your commit, and iterate on top of it in my own PR, you will then keep the authorship. |
|
OK, no pb |
|
here it is #19547 |
…which can't handle immutabledict
Pull Request Checklist
Pull request is based on the develop branch
Pull request includes a changelog file. The entry should:
EventStoretoEventWorkerStore.".code blocks.Code style is correct
(run the linters)
fixes: check_event_allowed callback from the module API cause a TypeError #18101