Skip to content

Run multiple event persisters when using Redis #972

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Oct 13, 2020
Merged

Run multiple event persisters when using Redis #972

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
51d24eb
Run multiple event persisters when using Redis
erikjohnston Oct 8, 2020
935782b
Fix flakey test
erikjohnston Oct 9, 2020
b18ed7c
Merge remote-tracking branch 'origin/develop' into erikj/periodic_poke
erikjohnston Oct 9, 2020
2fab331
Add comment
erikjohnston Oct 13, 2020
8d4d21d
Damn typos
erikjohnston Oct 13, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions tests/30rooms/60version_upgrade.pl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1070,6 +1070,8 @@ sub upgrade_room_synced {
$remote_joiner, $new_room_id, ( server_name => $creator->server_name, )
);
})->then(sub {
# The room list can be updated asynchrounously, so we retry if it
# doesn't match what we expect.
retry_until_success {
Copy link
Member

Choose a reason for hiding this comment

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

why are these changes necessary? And if they are really necessary, can we limit the number of times we retry, rather than going on forever?

Copy link
Member Author

@erikjohnston erikjohnston Oct 13, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

The test was flakey. This may no longer be necessary, but in general I don't think the public room lists get updated immediately (as they can be populated via background processes).

The retry_until_success will get killed by the test timeout, which is how we use retry_until_success/repeat_until_true elsewhere?

Copy link
Member

Choose a reason for hiding this comment

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

could you add a comment to say that we're retrying because the directory is updated asynchonously, or sth.

My main gripe with retry_until_success is that it turns test failures into test timeouts, which we tend to ignore as "oh we had a slow VM for random reasons", so a limit on the number of retries is preferable if possible.

The other problem with retry_until_success is that it swallows the failure, so you can't see what's going wrong. https://github.com/matrix-org/sytest/blob/develop/tests/30rooms/04messages.pl#L387-L408 includes a bunch of code to log what's going on, but on closer inspection maybe we should put all that boilerplate into retry_until_success (which could maybe also benefit from a "try N times" param which defaults to something other than "infinity").

Copy link
Member Author

Choose a reason for hiding this comment

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

Have added a comment.

Yeah, I think that sounds like a general issue with retry_until_success. We use this pattern a lot so it feels like something to investigate and improve separately.

do_request_json_for( $creator,
method => "GET",
Expand All @@ -1093,6 +1095,8 @@ sub upgrade_room_synced {
})
}
})->then(sub {
# The room list can be updated asynchrounously, so we retry if it
# doesn't match what we expect.
retry_until_success {
do_request_json_for( $remote_joiner,
method => "GET",
Expand Down