-
Notifications
You must be signed in to change notification settings - Fork 186
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
Support MSC4140: Delayed events (Futures) #17326
Conversation
6b06bf0
to
6466bd1
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.
@AndrewFerr would it be possible to break this PR up into a few more logical commits? Currently it's roughly 1 commit with >1000 lines changed, which appears daunting to review 🙂
If on startup there are multiple delayed state events to be sent, do not send multiple events that target the same state key for a room.
Ironically, the reason I had squashed the commits was to try make it easier to review 🙃 I've now split them up to isolate what should be the most relevant components of the PR. |
When a delayed event is sent on-demand, let its timestamp be set to whatever time the event is sent at, like non-delayed events. Only timed-out delayed events should have their timestamps set to their timeout time, as that is the time they are meant to be sent.
as it converts fields (namely RoomIDs) to dicts too
Require non-empty delay ID in path
Add missing WHERE clause in branched case
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.
Thanks for all the time you've spent (and patiently waited) on this. This now looks good to me, and the added tests help.
I see you have a matching Complement branch here: matrix-org/complement#734. I assume you would like to hold off on merging this PR until those tests pass?
Finally, once this is merged and done, if you have some time to document how the whole mechanism works (however detailed or briefly) in https://element-hq.github.io/synapse/latest/development/internal_documentation/index.html, that would help future development efforts.
Yes, as long as it's permissible to merge Complement tests before any implementations are merged.
Noted! |
Typically we'll merge them at the same time. However, yes, technically the Complement tests can be merged beforehand, as they won't be enabled on |
(Complement CI is expected to fail until matrix-org/complement#734 is merged.) |
matrix-org/complement#734 has been merged. I've re-run the failed Complement jobs: https://github.com/element-hq/synapse/actions/runs/10891540744?pr=17326 |
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, assuming the Complement tests are happy.
They aren't 🙃 Looking into it now. The failures reproduce locally, so I should have a fix ready very soon. |
@AndrewFerr looks like there's complement failures on the delayed event tests: https://github.com/element-hq/synapse/actions/runs/10891540744/job/30325234632?pr=17326 Edit: GitHub failed to show your last comment 🤦 |
Looks like the Complement failures are false-positives when running in Postgres. I'm updating the Complement tests to account for that. |
The Postgres tests should be fixed by matrix-org/complement#737. They pass when I run them locally, in either monolith or worker mode. |
Head branch was pushed to by a user without write access
Alright, I added an extra commit to satisfy what the Complement test was failing on, and now we don't have to worry about merging matrix-org/complement#737 first. The test expects Strictly speaking, the test doesn't have to cover ordering on The other test failure was simply due to leftover data after the first test failed, so I wrote matrix-org/complement@6f86880 to make tests do some teardown to prevent unrelated failures later on. Note that all tests will continue to pass with matrix-org/complement#737, so it can still be merged safely, but now it is optional to do so 🙂 |
See: MSC4140
Pull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.(run the linters)