Conversation
This only works on postgres for now
Persist inside persist_events to guarantee it is done. After that txn, recheck soft failure.
MadLittleMods
left a comment
There was a problem hiding this comment.
Looked everything over but didn't full evaluate the sticky events part against the MSC or fully ponder weird corners.
| if not sticky_events_request.enabled: | ||
| return None | ||
| now = self.clock.time_msec() | ||
| from_id = from_token.stream_token.sticky_events_key if from_token else 0 |
There was a problem hiding this comment.
Should we copy this pattern?
synapse/synapse/handlers/sliding_sync/extensions.py
Lines 928 to 931 in 2f2b854
| # Consumers call 'get_sticky_events_in_rooms' which has `WHERE expires_at > ?` | ||
| # to filter out expired sticky events that have yet to be deleted. | ||
| DELETE_EXPIRED_STICKY_EVENTS_MS = 60 * 1000 * 60 # 1 hour | ||
| MAX_STICKY_DURATION_MS = 3600000 # 1 hour |
There was a problem hiding this comment.
In the client event creation, we should be preventing creating events that have duration greater than MAX_STICKY_DURATION_MS
| critical_auth_types = ( | ||
| EventTypes.JoinRules, | ||
| EventTypes.PowerLevels, | ||
| EventTypes.Member, | ||
| ) |
There was a problem hiding this comment.
Wondering how this plays with room versions. Do we need to be careful at all with forward compatibility, etc?
There was a problem hiding this comment.
Should we be using auth_types_for_event instead?
There was a problem hiding this comment.
I don't think we need to be that careful here. We will need to keep this updated if we make new room versions which break the current auth model though.
| 9. `groups_key`: `1` (note that this key is now unused) | ||
| 10. `un_partial_stated_rooms_key`: `379` | ||
| 11. `thread_subscriptions_key`: 4242 | ||
| 12. `sticky_events_key`: 4141 |
There was a problem hiding this comment.
Add it to the full example token above
Currently emits on joins and logs on receive, WIP.
1b0bbdd to
58d8395
Compare
683ed8c to
11472bb
Compare
52a03e6 to
36ccb90
Compare
|
This PR is being superseded, the first one replacing it will be #19365 (with more to follow) |
Part of: MSC4354 whose experimental feature tracking issue is #19409 Follows: #19340 (a necessary bugfix for `/event/` to set this metadata) Partially supersedes: #18968 This PR implements the first batch of work to support MSC4354 Sticky Events. Sticky events are events that have been configured with a finite 'stickiness' duration, capped to 1 hour per current MSC draft. Whilst an event is sticky, we provide stronger delivery guarantees for the event, both to our clients and to remote homeservers, essentially making it reliable delivery as long as we have a functional connection to the client/server and until the stickiness expires. This PR merely supports creating sticky events and receiving the sticky TTL metadata in clients. It is not suitable for trialling sticky events since none of the other semantics are implemented. Contains a temporary SQLite workaround due to a bug in our supported version enforcement: #19452 --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org> Co-authored-by: Eric Eastwood <erice@element.io>
This implements MSC4354: Sticky Events. To enable it, set this in
homeserver.yaml:Complement tests: matrix-org/complement#806
Pull Request Checklist
EventStoretoEventWorkerStore.".code blocks.