Skip to content

Remove messy WithWaitForLeave test clean-up in TestPartialStateJoin#894

Open
MadLittleMods wants to merge 4 commits into
mainfrom
madlittlemods/remove-messy-TestPartialStateJoin-cleanup
Open

Remove messy WithWaitForLeave test clean-up in TestPartialStateJoin#894
MadLittleMods wants to merge 4 commits into
mainfrom
madlittlemods/remove-messy-TestPartialStateJoin-cleanup

Conversation

@MadLittleMods

@MadLittleMods MadLittleMods commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Remove messy WithWaitForLeave test clean-up in TestPartialStateJoin

Follow-up to #880 which introduces a better way to avoid the test pollution and obsoletes the need for all of this cleanup logic. See the PR description there for a more complete context on why.

WithWaitForLeave was originally introduced in this context:

Many of the faster joins test flakes are due to the homeserver under test failing to contact Complement homeservers after they have been torn down. When this happens, subsequent tests can fail if they use a Complement homeserver that happens to have the same hostname:port as one which the homeserver under test has previously marked as offline.

-- #626

But thanks to #880 we no longer use the same hostname:port for engineered homeservers anymore.

And we can go even further with cleaning this up by removing the need for Destroy(...) altogether, see #895

Pull Request Checklist

// considered offline and interfere with subsequent tests.
t.Log("Cleaning up after test...")

awaitPartialStateJoinCompletion(t, psj.ServerRoom, psj.User)

@MadLittleMods MadLittleMods Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LLM review likes to call out that awaitPartialStateJoinCompletion(...) is necessary in order for the server handlers in handleStateIdsRequests(...)/handleStateRequests(...) to finish before the test does but I don't think it really gives any guarantee of anything.

What it's trying to say is that calling psj.fedStateIdsSendResponseWaiter.Finish() wakes up the waiter so the handler goroutine can keep running but we don't wait for that handler to finish here in Destroy(...). The LLM claims that awaitPartialStateJoinCompletion(...) (requests /members on the homeserver) makes sure that the /state_ids or /state goroutine handlers finish because those requests are necessary to resync the room (partial -> full state) which is necessary in order to serve /members.

That seems like a very tenuous connection. I see the race condition it's explaining but using this is the wrong mechanism.

And the only thing it's trying to protect from is t being used after the test finishes which would panic.

In any case, all of this isn't necessary with the second step of this cleanup in a follow-up PR: #895

And the tests still pass in the mean-time (theoretical flake)

Comment on lines -2532 to -2536
leaveSharedRoom = func() {
server2.WithWaitForLeave(t, server2Room, alice, func() {
alice.MustLeaveRoom(t, roomID)
})
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This in the function called leaveSharedRoom but the leave already happens above.

For context, this was added in #627 which was addressing the flakes caused by homeservers still participating in rooms after each test.

Which as the PR description explains, we have a better solution for now.

// It is idempotent and must be called once the test is finished.
// Specifically, it ensures that the partial state join completes and makes the joining user leave
// the room.
func (psj *partialStateJoinResult) Destroy(t *testing.T) {

@MadLittleMods MadLittleMods Jul 13, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a follow-up, we're removing this entire need for this function in #895

@MadLittleMods MadLittleMods marked this pull request as ready for review July 13, 2026 22:49
@MadLittleMods MadLittleMods requested review from a team as code owners July 13, 2026 22:49

@anoadragon453 anoadragon453 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused by the commit history. Did you mean to revert the first commit via the second @MadLittleMods?

@MadLittleMods

MadLittleMods commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

@anoadragon453 Yes. I tried removing everything, WithWaitForLeave and Destroy altogether, but it required a few more changes which I made in a follow-up PR instead, see details in #895 (comment)

This is a first step which just removes WithWaitForLeave

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants