-
Notifications
You must be signed in to change notification settings - Fork 383
Add experimental support for MSC4308: Thread Subscriptions extension to Sliding Sync when MSC4306 and MSC4186 are enabled. #18695
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
Conversation
7634587
to
ba41526
Compare
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 have looked things over but haven't given everything a proper review-level scrutiny)
ba41526
to
6165651
Compare
6165651
to
f4cd180
Compare
previously-reviewed draft was very different, so putting back on the main queue |
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.
Looks good overall! A few minor things below.
Also curious that the CI was cancelled. I assume that was on purpose?
When creating a new sequence for a new stream, it will be necessary to advance it | ||
so that position 1 is consumed. | ||
DO NOT USE `START WITH 2` FOR THIS PURPOSE: | ||
see https://github.com/element-hq/synapse/issues/18712 | ||
Instead, use `SELECT nextval('sequence_name');` immediately after the | ||
`CREATE SEQUENCE` statement. |
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.
Should we close #18712 once this PR is merged?
Unless we plan to fix it in some other fashion down the line.
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.
Hrmrmrmr. It feels like a design footgun that we could ideally resolve rather than having a hidden comment somewhere about what to do. But not sure if that's worth keeping an issue in the infinite backlog.
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.
IMO there's not too much benefit gained from properly fixing it vs. other things we could work on. So in a purely triage sense, I'd be in favour of closing the issue and leaving the comment as a helpful touch stone (one that may prompt folks to fix it in future if they really wanted to).
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.
Somewhat agreed, but the comment is not necessarily in a place you will notice (I'm not sure where you could do that, actually). The risk is that next time we come to adding a new one, we lose another couple of hours trying to track this issue down. But mrm I suppose this is probably the best we can do atm
if limit <= 0: | ||
raise SynapseError( | ||
HTTPStatus.BAD_REQUEST, | ||
"limit must be greater than 0", | ||
errcode=Codes.INVALID_PARAM, | ||
) |
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.
negative=False
on parse_integer
will already do this for us.
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.
negative still allows 0
:(
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.
Ah, that's annoying.
Could you add a quick comment noting that this conditional is needed because of that?
tests/rest/client/sliding_sync/test_extension_thread_subscriptions.py
Outdated
Show resolved
Hide resolved
…ions.py Co-authored-by: Andrew Morgan <[email protected]>
Co-authored-by: Andrew Morgan <[email protected]>
Co-authored-by: Andrew Morgan <[email protected]>
@@ -100,6 +118,129 @@ async def on_DELETE( | |||
return HTTPStatus.OK, {} | |||
|
|||
|
|||
class ThreadSubscriptionsPaginationRestServlet(RestServlet): |
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.
What do you think about adding rate-limiting to this handler?
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.
hmm... do we rate-limit any read operations already?
Just looking at https://spec.matrix.org/v1.15/client-server-api/#get_matrixclientv3roomsroomidmessages and sync and I'm not seeing them be rate limited.
Not that it's a terrible idea, but not sure how to balance with consistency (and the fact you could rate limit general requests with a load balancer e.g. nginx for instance)
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 mostly asked the question to check that it had been considered (which we tend to forget to do when adding new endpoints).
I'll accept the argument that the endpoint can be rate-limited by IP or access token in the load balancer for now, as I agree that we don't need anything more granular. We also have a MAX_LIMIT
value defined, which prevents any one request from drawing too many resources.
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 LGTM!
(I assume Complement CI will fail until #18819 is merged?) |
Closes: #18436
Implements: matrix-org/matrix-spec-proposals#4308
Follows: #18674
This pull request is intended for commit-by-commit review.
This pull request adds an extension to Sliding Sync and a companion endpoint needed for backpaginating missed thread subscription changes,
as described in MSC4308