Open Gnuxie opened 2 months ago
Seems like another problem that essentially boils down to /createRoom
not being atomic, e.g. https://github.com/matrix-org/synapse/issues/8895
I maintain that the system admin was oblivious to any synapse modules, bots, or appservices that could be causing this issue.
This is peculiar; if you could convince them to provide logs that would be interesting indeed.
Wild speculation: Don't suppose it might be a case where @invited_moderator:example.com
is creating a room and inviting itself?
Aside from that, the problem with modules is itself unfortunate.
Description
We were offering support to a system admin setup up a Draupnir instance, and when they tried to use Draupnir's
list create
command (which in turn calls/createRoom
), their Synapse tripped up on this event authorization code and returned the following response to Draupnir.POST /_matrix/client/v3/createRoom: 403 Forbidden -- {"errcode":"M_FORBIDDEN","error":"@invited_moderator:example.com is already in the room."}
This is because Draupnir sets the
invite
option for/createRoom
to["@invited_moderator:example.com"]
, however for some reason that we have not been able to work out (because/createRoom
failing during event authorization is particularly unhelpful) Synapse believed@invited_moderator:example.com
to already be present within the room. While the system admin believes there are no bots, synapse modules, or appservices which would inject their membership into the newly created room, we cannot provide that guarantee. You should ask yourself whether it would be possible for a Synapse module, bridge or bot to inject membership events into a room before Synapse has even responded to the/createRoom
request that is supposed to create the room. And you should then ask yourself whether it is safe or sound for a synapse module to inject events into a room before Synapse has finished processing the/createRoom
request. Specifically because this causes the request to fail for the innocent client, rather than the clobbering performed by the synapse module or appservice to fail -- the wrong party is getting hit for playing around unsafely.I maintain that the system admin was oblivious to any synapse modules, bots, or appservices that could be causing this issue.
Steps to reproduce
These steps that could reproduce the failure mode, this is not how the failure mode was experienced, and I have not tested them and am not going to do without some persuasion.
@bob:example.com
@bob:example.com
into the membership of each newly created room uponm.room.create
@alice:example.com
, call/createRoom
with@bob:example.com
in theinvite
option.Homeserver
unknown
Synapse Version
v1.98.0
Installation Method
I don't know
Database
unknown
Workers
Single process
Platform
unknown - the version provided is accurate though.
Configuration
No response
Relevant log output
Anything else that would be useful to know?
No response