-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Synapse accepts a PUT /createRoom request #14535
Comments
matrix-org/matrix-spec#222 confuses the matter somewhat |
Pinged clients here'; no requests to |
Hmm. On reflection it looks like the implementation is handling a transaction id: synapse/synapse/rest/client/room.py Lines 153 to 158 in 86c5a71
which means it's doing exactly what matrix-org/matrix-spec#222 asks for. Maybe we just add this to the spec? |
How is it handling a transaction ID without a transaction ID parameter in the path? Also, is it actually idempotent or does it just eat a transaction ID and do nothing with it? I'd say it's safe to remove either way and re-add properly once there's a MSC. |
See synapse/synapse/rest/client/room.py Lines 149 to 151 in 86c5a71
and the implementation of register_txn_path.
It looks idempotent enough to me. The transaction id is included here in the key we use to deduplicate requests: synapse/synapse/rest/client/transactions.py Lines 70 to 85 in fa0eab9
synapse/synapse/rest/client/transactions.py Lines 53 to 68 in fa0eab9
A comment suggests that we guarantee deduplication within a 30 minute range. synapse/synapse/rest/client/transactions.py Lines 46 to 50 in fa0eab9
|
Huh, so synapse also has undocumented PUT versions of all the membership and join endpoints 🤔 I guess that just needs a MSC for PUT /createRoom then, although it'd be nice to switch to |
But the spec says it's only to be POSTed.
https://spec.matrix.org/v1.5/client-server-api/#creation
In particular, /createRoom is not idempotent, so it shouldn't be a PUT.
The text was updated successfully, but these errors were encountered: