Fix 404 during project reset test #740
Conversation
Now that we've removed the race condition in ResetProject, we no longer need to wait for the hgweb refresh interval in the middle of the SendReceiveAfterProjectReset tests. (We still do need to wait for it at the start of the test, after project creation).
If the zip file uploaded during the reset project step had no .hg directory anywhere inside it, we want to delete it entirely before presenting the error message to the user. Otherwise we might leave quite large amounts of useless data lying around in the repos volume.
|
So, I commited a test that sadly didn't manage to reproduce the 404 😢, but it still fairly heavily tests this feature, so it seems reasonable to keep it around. And then I resolved a merge conflict I introduced 😉 |
I added that in commit b2f6ef0, but without using a job. That way: 1) it will fail quickly if we're going to get 404s on the newly-reset project, so we'll find out sooner if we've solved the problem with hgweb or not. And 2) unlike Send/Receive, the FinishReset process is not especially time-sensitive, so updating the lex entry count immediately doesn't matter nearly as much as it does in a Send/Receive scenario. However, if I'm proved wrong about those points, I'll push another commit moving this to a job. |
…get a temp repo path
|
Okay, I tried to reply to multiple comments at once in the Files view of the PR, so that you'd only get a single notification email. But this is how GitHub formats it when you do that? Ugly. From now on I'll just reply in the Conversation view, where the formatting is much better. You'll get a notification email for each reply — sorry about that — but it'll be much easier to follow the conversation. |
This saves seeral seconds of test setup time.
This allows the project to build when MercurialVersion is set to 6.
|
@myieye - Let me know what you think of the change I made to your IntegrationFixture code, where instead of downloading a .zip file and creating an hg commit inside it, we just store the .zip file in our Git repo (and it already has the .hg folder inside it so we don't need to create a new commit). The one behavior change that this makes is that with your code, the template repo would have a different initial commit hash every time you run the tests (but it would have the same initial commit hash for every test run during a single As far as I can tell, none of our tests actually relied on the initial commit hash being unpredictable and/or changing from run to run, so I think this change has no downsides. But if it does become a problem sometimes, we can always copy the template repo, delete |
The user typeahead had two debounces, one in the input and one in the typeahead store. The debounce in the input was causing Playwright tests to fail because they were filling in the input and expecting the form to be valid immediately, but it wasn't valid until the debounce triggered. The debounce on the input now serves no purpose; removing it.
Many times the Playwright code gets to the email page before the email has actually shown up. So we need to make it wait for up to 10 seconds, refreshing the email list periodically (because mailDev, at least, doesn't auto-refresh: you have to click the refresh button).
…-404 Fixes merge conflicts, and I've verified that the GetLexEntryCount changes for WeSay are still correct.
There was a problem hiding this comment.
I did a bit more Playwright stuff and added some mocking so that @hahn-kev's new Fixture tests aren't implicitly integration tests any more.
I'd like to get the test fixes and improvements into the next release. So, I'm gonna merge this.
@hahn-kev I wouldn't be surprised if you'd have done things slightly differently...feel free to refactor of course.
Looks to me like I will need to make it a job: running the update immediately after FinishReset is, for some reason, returning 0 (because Mercurial still sees the repo as being empty and thinks |
|
I can confirm that this PR unfortunately didn't fix the 404s. |
Fixes #728.
This fixes the race conditions I identified in #728 (comment) by narrowing the window during which they can happen from seconds to microseconds. It's still theoretically possible that the hgweb refresh scan might happen to trigger right between the project being deleted and the new project being moved into place, but the chances of that happening are miniscule, and we should see it only once in a blue moon.