-
-
Notifications
You must be signed in to change notification settings - Fork 613
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add .m.rule.is_room_mention
push rule to DEFAULT_OVERRIDE_RULES
#4100
Conversation
Signed-off-by: Michael Telatynski <[email protected]>
Signed-off-by: Michael Telatynski <[email protected]>
.m.rule.is_room_mention
push rule to DEFAULT_OVERRIDE_RULES
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this still needs to happen before existing push rules?
The spec doesn't state that the defaults are ordered as far as I can tell, we can't assume what order the server actually holds the rules in. The spec says rules can specify an ordering priority within a kind and that |
You absolutely can. I'm afraid that, whatever the words of the spec might say, the ordering of the push rules is very very important. If that's not obvious from the spec, then clarification PRs welcome, but it doesn't change anything here. Note that MSC3952 explicitly says where the new push rule fits in:
|
In which case the current code is already not spec compliant as it appends |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, .m.rule.reaction
is safe to reorder with respect to .m.rule.room.server_acl
at least, because they cannot both match on the same event. .m.rule.is_room_mention
is quite a bit earlier so I don't think we can et away with the same bodge.
We just need a list of the rule_ids
for all the override rules, so that pushprocessor.ts can put them in the right order.
The client ignores
Wouldn't this break if the spec adds a new rule inbetwixt other existing rules especially when MSC-namespaced rules are also in play, as they currently are in the hardcoded list |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, .m.rule.reaction is safe to reorder with respect to .m.rule.room.server_acl at least, because they cannot both match on the same event. .m.rule.is_room_mention is quite a bit earlier so I don't think we can et away with the same bodge.
The client ignores
.m.rule.is_room_mention
if the event hasm.mentions
so this should be fine
Ok, but what about the other rules that come after .m.rule.is_room_mention
? They might be fine but please could you add a comment explaining why it's safe for each of them to happen before .m.rule.is_room_mention
?
We just need a list of the rule_ids for all the override rules, so that pushprocessor.ts can put them in the right order.
Wouldn't this break if the spec adds a new rule inbetwixt other existing rules especially when MSC-namespaced rules are also in play, as they currently are in the hardcoded list
I don't follow, I'm afraid. I'm thinking of an algorithm that iterates through the current rules, comparing them against the expected rules, and inserting the new ones where needed.
EXPECTED_OVERRIDE_RULE_IDS = [".m.rule.master", ".m.rule.suppress_notices", /* ... */ ".m.rule.suppress_edits"];
let next_expected_rule_id_index = 0;
let new_rules = [];
for (rule of current_rules) {
if (!rule.default) {
// got to the end of the default list
break;
}
const rule_index = EXPECTED_OVERRIDE_RULE_IDS.indexOf(rule.rule_id);
if (rule_index === -1) {
// an unrecognised rule; copy it over
new_rules.push(rule);
continue;
}
while (rule_index > next_expected_rule_index) {
// insert new rules
new_rules.push(EXPECTED_OVERRIDE_RULE_IDS[next_expected_rule_index]);
next_expected_rule_index += 1;
}
// copy over the existing rule
new_rules.push(rule);
next_expected_rule_index += 1;
}
// TODO: now copy over any remaining EXPECTED_OVERRIDE_RULE_IDS, and finally any
// non-default rules that were in `current_rules`.
Now, if the spec adds a new rule which we don't know about but the server does, we'll just copy it over. Right? What's the failure mode you're thinking of?
[yes, the need to do all of this complexity is horrible. Push rules in general are horrible, and I wish we'd get rid of them rather than continually trying to patch the system with "just one more push rule". But here we are.]
If the server adds Y between X & Z (X, Y, Z) but we already have a local MSC rule M in order X, M, Z. Now we don't know the total order, is it XMYZ or XYMZ, one may cause buggy behaviour |
I mean, that's kinda on you for adopting MSC rules before they are specced. If the MSC doesn't take a view on whether it goes before or after Y, then everything implementing that MSC is basically broken because we have no idea what different implementations will do. Presumably that shouldn't be a problem in practice, because by the time Y is specced, M has either itself been specced, or has failed to do so (in which case it seems like high time to rip it out of the codebase). Anyway, can't we cross that bridge if/when we come to it? It's all a bit hypothetical and doesn't seem of much relevance to how we can implement this particular change correctly? |
Signed-off-by: Michael Telatynski <[email protected]>
Signed-off-by: Michael Telatynski <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally I feel like this is a bit under-tested, and it would lend itself well to unit tests which directly call rewriteDefaultRules
. The special-casing of is_user_mention
, and the fact that we update conditions
and actions
seems important, and I'm worried that we can rip it out without the tests caring.
Signed-off-by: Michael Telatynski <[email protected]>
The special-casing that you just convinced me we don't need |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🎉
* v31.5.0-rc.0 * Don't re-fetch thread root if we already have it (matrix-org#4088) The root event of a thread used to arrive with the pagination request, but this was unspecced and so got changed to simply fetch the root event. In many (almost all) cases this shouldn't be necessary because the thread should already have its root event: re-use it if it's already there. This is only in pagination, so there's no reason to believe that the root event would have changed and needs to be re-fetched. This removes a number of duplicate calls to the /event/ endpoint from the tests. * Fix race condition with sliding sync extensions (matrix-org#4089) * Fix race condition with sliding sync extensions * Fix types on sliding-sync spec test * Prettier fixes * Add `.m.rule.is_room_mention` push rule to DEFAULT_OVERRIDE_RULES (matrix-org#4100) * Add intentional mentions push rules to DEFAULT_OVERRIDE_RULES Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> * Export types describing all specced media event formats (matrix-org#4092) * Export types describing all specced media event formats Signed-off-by: Michael Telatynski <[email protected]> * Iterate PR Signed-off-by: Michael Telatynski <[email protected]> * Move types to a dedicated export Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Add readme entry Signed-off-by: Michael Telatynski <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> * Update dependency typedoc to v0.25.11 (matrix-org#4102) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> * v31.5.0 * Resetting package fields for development * Temporarily disable broken step in the release process Signed-off-by: Michael Telatynski <[email protected]> * fix automatic DM avatar with functional members (matrix-org#4017) * fix automatic DM avatar with functional members * update comments * lint * add tests for functional members * keep functional members out of the public API - remove public API for functional members, reverting most of 0ce2d82, f9b41f6, e65fb24 - remove tests for functional members public API c114bf5 - add shared functional members getter for both room name and avatar fallback generation * filter functional members from more candidates - remove from hero(es) - remove from previous members * add tests for fallback avatars with functional members * Add docstring for getFunctionalMembers Co-authored-by: Richard van der Hoff <[email protected]> * inline getInvitedAndJoinedFunctionalMemberCount * update comments for getAvatarFallbackMember * use correct list of heroes in getAvatarFallbackMember * remove redundant type annotation * optimize performance of invitedAndJoinedFunctionalMemberCount * calculate nonFunctionalMemberCount in one step instead of iterating redundantly * clean up functional member tests with review feedback * lint * Update src/models/room.ts Co-authored-by: Richard van der Hoff <[email protected]> * apply feedback about comments * non-functional per review, lint --------- Co-authored-by: Richard van der Hoff <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> Co-authored-by: RiotRobot <[email protected]> Co-authored-by: David Baker <[email protected]> Co-authored-by: Daniel Salinas <[email protected]> Co-authored-by: Michael Telatynski <[email protected]> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Kim Brose <[email protected]> Co-authored-by: Richard van der Hoff <[email protected]>
* v31.5.0-rc.0 * Don't re-fetch thread root if we already have it (matrix-org#4088) The root event of a thread used to arrive with the pagination request, but this was unspecced and so got changed to simply fetch the root event. In many (almost all) cases this shouldn't be necessary because the thread should already have its root event: re-use it if it's already there. This is only in pagination, so there's no reason to believe that the root event would have changed and needs to be re-fetched. This removes a number of duplicate calls to the /event/ endpoint from the tests. * Fix race condition with sliding sync extensions (matrix-org#4089) * Fix race condition with sliding sync extensions * Fix types on sliding-sync spec test * Prettier fixes * Add `.m.rule.is_room_mention` push rule to DEFAULT_OVERRIDE_RULES (matrix-org#4100) * Add intentional mentions push rules to DEFAULT_OVERRIDE_RULES Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> * Export types describing all specced media event formats (matrix-org#4092) * Export types describing all specced media event formats Signed-off-by: Michael Telatynski <[email protected]> * Iterate PR Signed-off-by: Michael Telatynski <[email protected]> * Move types to a dedicated export Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Add readme entry Signed-off-by: Michael Telatynski <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> * Update dependency typedoc to v0.25.11 (matrix-org#4102) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> * v31.5.0 * Resetting package fields for development * Temporarily disable broken step in the release process Signed-off-by: Michael Telatynski <[email protected]> * fix automatic DM avatar with functional members (matrix-org#4017) * fix automatic DM avatar with functional members * update comments * lint * add tests for functional members * keep functional members out of the public API - remove public API for functional members, reverting most of 0ce2d82, f9b41f6, e65fb24 - remove tests for functional members public API c114bf5 - add shared functional members getter for both room name and avatar fallback generation * filter functional members from more candidates - remove from hero(es) - remove from previous members * add tests for fallback avatars with functional members * Add docstring for getFunctionalMembers Co-authored-by: Richard van der Hoff <[email protected]> * inline getInvitedAndJoinedFunctionalMemberCount * update comments for getAvatarFallbackMember * use correct list of heroes in getAvatarFallbackMember * remove redundant type annotation * optimize performance of invitedAndJoinedFunctionalMemberCount * calculate nonFunctionalMemberCount in one step instead of iterating redundantly * clean up functional member tests with review feedback * lint * Update src/models/room.ts Co-authored-by: Richard van der Hoff <[email protected]> * apply feedback about comments * non-functional per review, lint --------- Co-authored-by: Richard van der Hoff <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> Co-authored-by: RiotRobot <[email protected]> Co-authored-by: David Baker <[email protected]> Co-authored-by: Daniel Salinas <[email protected]> Co-authored-by: Michael Telatynski <[email protected]> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Kim Brose <[email protected]> Co-authored-by: Richard van der Hoff <[email protected]>
* v31.5.0-rc.0 * Don't re-fetch thread root if we already have it (matrix-org#4088) The root event of a thread used to arrive with the pagination request, but this was unspecced and so got changed to simply fetch the root event. In many (almost all) cases this shouldn't be necessary because the thread should already have its root event: re-use it if it's already there. This is only in pagination, so there's no reason to believe that the root event would have changed and needs to be re-fetched. This removes a number of duplicate calls to the /event/ endpoint from the tests. * Fix race condition with sliding sync extensions (matrix-org#4089) * Fix race condition with sliding sync extensions * Fix types on sliding-sync spec test * Prettier fixes * Add `.m.rule.is_room_mention` push rule to DEFAULT_OVERRIDE_RULES (matrix-org#4100) * Add intentional mentions push rules to DEFAULT_OVERRIDE_RULES Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> * Export types describing all specced media event formats (matrix-org#4092) * Export types describing all specced media event formats Signed-off-by: Michael Telatynski <[email protected]> * Iterate PR Signed-off-by: Michael Telatynski <[email protected]> * Move types to a dedicated export Signed-off-by: Michael Telatynski <[email protected]> * Iterate Signed-off-by: Michael Telatynski <[email protected]> * Add readme entry Signed-off-by: Michael Telatynski <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> * Update dependency typedoc to v0.25.11 (matrix-org#4102) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> * v31.5.0 * Resetting package fields for development * Temporarily disable broken step in the release process Signed-off-by: Michael Telatynski <[email protected]> * fix automatic DM avatar with functional members (matrix-org#4017) * fix automatic DM avatar with functional members * update comments * lint * add tests for functional members * keep functional members out of the public API - remove public API for functional members, reverting most of 0ce2d82, f9b41f6, e65fb24 - remove tests for functional members public API c114bf5 - add shared functional members getter for both room name and avatar fallback generation * filter functional members from more candidates - remove from hero(es) - remove from previous members * add tests for fallback avatars with functional members * Add docstring for getFunctionalMembers Co-authored-by: Richard van der Hoff <[email protected]> * inline getInvitedAndJoinedFunctionalMemberCount * update comments for getAvatarFallbackMember * use correct list of heroes in getAvatarFallbackMember * remove redundant type annotation * optimize performance of invitedAndJoinedFunctionalMemberCount * calculate nonFunctionalMemberCount in one step instead of iterating redundantly * clean up functional member tests with review feedback * lint * Update src/models/room.ts Co-authored-by: Richard van der Hoff <[email protected]> * apply feedback about comments * non-functional per review, lint --------- Co-authored-by: Richard van der Hoff <[email protected]> --------- Signed-off-by: Michael Telatynski <[email protected]> Co-authored-by: RiotRobot <[email protected]> Co-authored-by: David Baker <[email protected]> Co-authored-by: Daniel Salinas <[email protected]> Co-authored-by: Michael Telatynski <[email protected]> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Kim Brose <[email protected]> Co-authored-by: Richard van der Hoff <[email protected]>
To handle the client not knowing it due to the server not proactively telling us down incremental syncs