bug: spurious warning: `Could not parse incoming PDU: NotFound: no version associated with room ID` #2241

New issue

Open

opened 2026-09-13 03:51:20 +00:00 by nex · 0 comments

nex commented

2026-09-13 03:51:20 +00:00

Owner

What is the bug?

#2075 introduced a (cosmetic) regression that causes PDUs being received on PUT /_matrix/federation/v1/send/{txnId} that belong to a room continuwuity has never (finished) joining to emit a warning, like the following:

2026-09-13T01:03:34.264260Z  WARN transaction{id="1789063418080" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID
2026-09-13T01:04:44.259325Z  WARN transaction{id="1789063418395" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID
2026-09-13T01:06:47.472683Z  WARN transaction{id="1789063418713" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID
2026-09-13T01:07:00.123379Z  WARN transaction{id="1789063419029" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID
2026-09-13T01:12:35.987993Z  WARN transaction{id="1789103957668" origin="fedora.im"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID
2026-09-13T01:12:57.392937Z  WARN transaction{id="1789103958137" origin="fedora.im"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID

Prior to that PR, continuwuity would silently ignore (well, apparently it silently illegally processed?) PDUs received for rooms the server isn't a resident of - this is the intended and typical behaviour. This is an edge case where send_join failed (e.g. timed out) but remote servers think the local server is a resident, so are sending it data, when in reality the local server has no knowledge of the target room.

Steps to reproduce

Join a really large remote room
Yank your Ethernet cable out (or make the send_join request fail in some other way)
Send (or wait for someone else to send) an event in the room you now failed to join

Server name and version

continuwuity.rocks - 26.8.1 (06825fdddb)

Additional context

No response

### What is the bug? #2075 introduced a (cosmetic) regression that causes PDUs being received on `PUT /_matrix/federation/v1/send/{txnId}` that belong to a room continuwuity has never (finished) joining to emit a warning, like the following: ``` 2026-09-13T01:03:34.264260Z WARN transaction{id="1789063418080" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID 2026-09-13T01:04:44.259325Z WARN transaction{id="1789063418395" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID 2026-09-13T01:06:47.472683Z WARN transaction{id="1789063418713" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID 2026-09-13T01:07:00.123379Z WARN transaction{id="1789063419029" origin="im.kde.org"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID 2026-09-13T01:12:35.987993Z WARN transaction{id="1789103957668" origin="fedora.im"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID 2026-09-13T01:12:57.392937Z WARN transaction{id="1789103958137" origin="fedora.im"}: conduwuit_api::server::send: Could not parse incoming PDU: NotFound: no version associated with room ID ``` Prior to that PR, continuwuity would silently ignore (well, apparently it silently illegally processed?) PDUs received for rooms the server isn't a resident of - this is the intended and typical behaviour. This is an edge case where `send_join` failed (e.g. timed out) but remote servers think the local server is a resident, so are sending it data, when in reality the local server has no knowledge of the target room. ### Steps to reproduce 1. Join a really large remote room 2. Yank your Ethernet cable out (or make the `send_join` request fail in some other way) 3. Send (or wait for someone else to send) an event in the room you now failed to join ### Server name and version continuwuity.rocks - 26.8.1 (06825fdddba6f2ad3eb940f3f034eaa52ccc5ae3) ### Additional context _No response_

nex added the

labels

2026-09-13 03:51:20 +00:00