-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
debug Test{AD,IPA}.testQualifiedUsers #19578
Conversation
I tried to reproduce this locally, by repeating the login, but that passes. So I really need a trace-enabled failed log from the bots. --- test/verify/check-system-realms
+++ test/verify/check-system-realms
@@ -161,7 +161,11 @@ class CommonTests:
self.admin_password, self.admin_user), timeout=300)
# log in as domain admin and check that we can do privileged operations
- b.login_and_go('/system/services#/systemd-tmpfiles-clean.timer', user=f'{self.admin_user}@cockpit.lan', password=self.admin_password)
+ for _ in range(30):
+ b.login_and_go('/system/services#/systemd-tmpfiles-clean.timer', user=f'{self.admin_user}@cockpit.lan', password=self.admin_password)
+ time.sleep(5)
+ b.logout()
+ time.sleep(3)
return
b.wait_in_text("#statuses", "Running")
This log provides one. First the logout:
and then the login:
This is very strange -- context 9 is still from the "old" login page after logout. So it seems this is somehow "too fast" with filling out the login page, before the new one from Page.navigate() even loads. Locally I see the execution context destruction earlier, where it doesn't hurt:
That leaves the question what context this is -- it may be a delayed effect from logout, or the login page really does a page reload. I created a much faster toy test to study this: self.login_and_go("/system", user="user")
time.sleep(3)
b.logout()
time.sleep(3)
print("XXXXXXX second login")
b.login_and_go("/system", user="user") FirefoxFirst login:
... and then no further execution context changes until clicking the login button. Then the logout and second login looks similar: It destroys the execution context from the previous login page, whose error message hits the first wait command after the Page.navigate():
ChromiumIt looks similar -- the Page.navigate() destroys the initial "empty tab" execution context, loads the login page's, and keeps it until clicking the Login button:
Logout / second login is again similar:
So my gut feeling is that the Page.navigate() doesn't wait for the new execution context to get loaded, and that error message just hits a random next wait command. I also triggered another run to see the "execution context created/destroyed" messages in the check-realms logs. |
2f7b3da
to
5b6736e
Compare
Commit 8284618 dropped all explicit "wait for page load" calls (fka. `expect_load()`) in favor of allowing page loads during wait commands. This is better in almost all cases, but it created a race condition in tests which logged out and back in. In particular: ... TODO
Bazinga! I sent #19583 for landing and running all tests. |
Investigating these failures which have a 30% failure rate, but only with firefox.