Sean Quah
Sean Quah
@dependabot rebase
@dependabot recreate
I suspect this has the same cause as https://github.com/matrix-org/synapse/issues/13977. Because the test did not wait for the partial state join to complete fully, the final device list update happened before...
It's happened again despite https://github.com/matrix-org/complement/pull/487 https://github.com/matrix-org/synapse/actions/runs/3188796603/jobs/5201917557#step:6:2936 ``` client.go:604: [CSAPI] GET hs1/_matrix/client/v3/rooms/!0:host.docker.internal:39435/members => 200 OK (82.12876ms) federation_room_join_partial_state_test.go:1681: @t24alice:hs1's partial state join to !0:host.docker.internal:39435 completed. client.go:604: [CSAPI] PUT hs1/_matrix/client/v3/devices/HDRGUEKYVH => 200 OK...
> It's happened again despite https://github.com/matrix-org/complement/pull/487 > https://github.com/matrix-org/synapse/actions/runs/3188796603/jobs/5201917557#step:6:2936 Actually this failure mode is different to the original issue. Here the 2nd device list update is duplicated, instead of the 3rd.
This is a pretty annoying failure mode, since it causes complement to take a full hour to time out.
Currently, the second join will block until Synapse finishes syncing state. While not _incorrect_, it's not a great experience and we should be able to allow some membership changes before...
related to https://github.com/matrix-org/synapse/issues/13783
I reckon the tests are picking up the spurious `device_lists.changed` instead of the real one and advancing too early.
Those tests are for incoming device list updates rather than outgoing ones. We're missing tests for this issue.