Two subtests sample time.Now() and immediately probe a homeserver that stamps events using its own millisecond clock; when the two readings land in the same millisecond, the subtest fails through no fault of the implementation. In should_find_event_after_given_timestamp, timeBeforeEventA = time.Now() is sampled after MustCreateRoom returns, but the last state event from createRoom (m.room.guest_access in our recent run) was stamped at the same ms. Forward from that ms inclusively finds the state event before reaching the message that the test wants. In should_find_nothing_before_the_earliest_timestamp, timeBeforeRoomCreation is sampled and the very next m.room.create is stamped at the same ms; Backward returns the create event when the test wants 404. Both probes are racing the Matrix /timestamp_to_event API itself, which is ms-granular by spec, so no implementation can disambiguate the boundary.
The simplest fix is a time.Sleep(2*time.Millisecond) immediately after each time.Now() sample in createTestRoom and in the timeBeforeRoomCreation block, ensuring at least one full ms separates the sample from any subsequent server-side stamp. We have observed these two subtests flake on otherwise green runs across multiple homeserver implementations; happy to send a PR if a guard sleep is acceptable.
Two subtests sample
time.Now()and immediately probe a homeserver that stamps events using its own millisecond clock; when the two readings land in the same millisecond, the subtest fails through no fault of the implementation. Inshould_find_event_after_given_timestamp,timeBeforeEventA = time.Now()is sampled afterMustCreateRoomreturns, but the last state event from createRoom (m.room.guest_accessin our recent run) was stamped at the same ms.Forwardfrom that ms inclusively finds the state event before reaching the message that the test wants. Inshould_find_nothing_before_the_earliest_timestamp,timeBeforeRoomCreationis sampled and the very nextm.room.createis stamped at the same ms;Backwardreturns the create event when the test wants 404. Both probes are racing the Matrix/timestamp_to_eventAPI itself, which is ms-granular by spec, so no implementation can disambiguate the boundary.The simplest fix is a
time.Sleep(2*time.Millisecond)immediately after eachtime.Now()sample increateTestRoomand in thetimeBeforeRoomCreationblock, ensuring at least one full ms separates the sample from any subsequent server-side stamp. We have observed these two subtests flake on otherwise green runs across multiple homeserver implementations; happy to send a PR if a guard sleep is acceptable.