fix: Avoid v12 room ID collisions when creating rooms concurrently #2433
Labels
No labels
Abandoned
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
bob the builder
No milestone
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
continuwuation/continuwuity!2433
Loading…
Reference in a new issue
No description provided.
Delete branch "eleboucher/continuwuity:fix/v12-room-id-collision"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #2424. v12 rooms created by the same user in the same millisecond got the same room ID, so they ended up as one room. Room creation now locks on the room ID and bumps origin_server_ts by 1ms until the ID is free (up to 5 tries, like Synapse), and returns M_ROOM_IN_USE if the client set the timestamp itself.
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
I already said the 5-retries thing is dumb, just do a random sleep of 1-100ms on each /createRoom call
@ -289,2 +313,4 @@};// v12+ room IDs are the create event's hash, so give each create event a// unique timestamp to avoid collisions (see MSC4291)nit: There's no need to reference the MSC when the proposal is in the spec at the time of implementing