This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Check appservice user interest against the local users instead of all users (
get_users_in_room
mis-use) #13958Check appservice user interest against the local users instead of all users (
get_users_in_room
mis-use) #13958Changes from all commits
99a623d
806b255
5f0f815
a8be41b
72985df
92b9da2
5d3c6a3
76435c7
4451998
1218f03
7bd3803
33f718c
cf8299b
3de90e6
ab33cd6
3223512
d913ceb
4f29e75
2665aa0
39e2ead
33a5b70
92400ff
426ef5c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
For more context on this comment, see #13958 (comment)
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 changes the behavior of
is_interested_in_room
slightly. Previously, we could match remote users when the appservice's user regex didn't include a hostname (all of our test cases and examples in the documentation don't). Was that just a bug?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.
I don't see how an appservice could control remote users, so I think so...but might be worth asking someone with more info?
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.
It's not really a question of controlling the users, but more of whether the application service wants to receive events and updates related to those users, which an application service may well want to do for events coming from non-local users.
So I think this is a change we wouldn't want to go ahead with.
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.
Interesting! I hadn't considered this use case.
For my own reference, the spec doesn't mention any restriction either: https://spec.matrix.org/v1.1/application-service-api/#registration
I've updated the comments to clarify local and remote so it's obvious if this is attempted again. We do have tests around this kinda but because they were just mocking
get_users_in_room
so they happily passed when I updated it toget_local_users_in_room
as well 🤦♂️. I've added some actual homeserver integration tests and verified that they fail if we useget_local_users_in_room
here ✅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.
Created #14000 to introduce these clarification changes with so we can leave the diff in this PR for reference of what we didn't want to do.
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.
Quite possibly, though the historical context (which may be lost to time) is still very prevelant here.
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.
Is there something specific to point to here? Or just from your memory?
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.
The implied parts of "r0 was a nightmare" above :p (mostly my memory, but also the memory of others from around that time)
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.
Created a MSC for this: MSC3905
And prodding this point in case we can merge earlier,
I tend to agree with @anoadragon453 here (I think we agree 😬). The use cases of seeing events from remote users (like moderation) is already supported by matching the entire room with the
rooms
namespace regex so this PR should be ok to merge.We have to rip the band-aid off at some point whether it before or after matrix-org/matrix-spec-proposals#3905 merges. Maybe there is a way to detect people relying on the old behavior? -> #13958 (comment)
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.
MSC3905 is merged and this behavior is ok to change now ✅
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.
A note to previous reviewers, this parameterized test is new!
Originally from #14000 but this integration test actually passes and fails based on Synapse's behavior instead of mocked functions.