Skip to content

Conversation

reivilibre
Copy link
Contributor

@reivilibre reivilibre commented Jul 18, 2025

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

@reivilibre reivilibre changed the title Add experimental support for [MSC4308: Thread Subscriptions extension to Sliding Sync](https://github.com/matrix-org/matrix-spec-proposals/pull/4308) when [MSC4306: Thread Subscriptions](https://github.com/matrix-org/matrix-spec-proposals/pull/4306) and [MSC4186: Simplified Sliding Sync](https://github.com/matrix-org/matrix-spec-proposals/pull/4186) are enabled. Add experimental support for MSC4308: Thread Subscriptions extension to Sliding Sync when MSC4306 and MSC4186 are enabled. Jul 18, 2025
@reivilibre reivilibre force-pushed the rei/ssext_threadsubs branch 3 times, most recently from 7634587 to ba41526 Compare July 21, 2025 17:32
@reivilibre reivilibre marked this pull request as ready for review July 21, 2025 20:13
@reivilibre reivilibre requested a review from a team as a code owner July 21, 2025 20:13
Copy link
Contributor

@MadLittleMods MadLittleMods left a 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)

@reivilibre reivilibre force-pushed the rei/ssext_threadsubs branch from 6165651 to f4cd180 Compare August 21, 2025 16:28
@reivilibre reivilibre requested a review from a team August 21, 2025 16:28
@reivilibre
Copy link
Contributor Author

previously-reviewed draft was very different, so putting back on the main queue

Copy link
Member

@anoadragon453 anoadragon453 left a 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?

Comment on lines +190 to +195
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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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).

Copy link
Contributor Author

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

Comment on lines 148 to 153
if limit <= 0:
raise SynapseError(
HTTPStatus.BAD_REQUEST,
"limit must be greater than 0",
errcode=Codes.INVALID_PARAM,
)
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

negative still allows 0 :(

Copy link
Member

@anoadragon453 anoadragon453 Sep 8, 2025

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?

@@ -100,6 +118,129 @@ async def on_DELETE(
return HTTPStatus.OK, {}


class ThreadSubscriptionsPaginationRestServlet(RestServlet):
Copy link
Member

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?

Copy link
Contributor Author

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)

Copy link
Member

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.

Copy link
Member

@anoadragon453 anoadragon453 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM!

@anoadragon453
Copy link
Member

anoadragon453 commented Sep 9, 2025

(I assume Complement CI will fail until #18819 is merged?)

@reivilibre reivilibre merged commit ada3a3b into develop Sep 11, 2025
104 of 112 checks passed
@reivilibre reivilibre deleted the rei/ssext_threadsubs branch September 11, 2025 13:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants