Second iteration of any windmill test that uses lpuser.ensure_login will fail
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Fix Released
|
Medium
|
Guilherme Salgado | ||
Bug Description
I have a test which was failing with a timeout (waiting for a page element) on ec2, so I did some changes to it and ran it on a loop (-N 10) to make sure it wouldn't timeout again. Much to my surprise it failed every other iteration. After running locally with -D I realized it was failing because the second iteration of the test would start on the page where the previous one left off. That means the ensure_login() call would operate on a stale page and think the user was already logged in, but when you reload the page (or open a new one), the user isn't actually logged in (thanks to the new WindmillTestClient, created in the setUp() method, I guess).
This could easily be fixed by making ensure_login() always reload the page before doing anything.
| Guilherme Salgado (salgado) wrote | #1 |
| Changed in launchpad-foundations: | |
| assignee: | nobody → Guilherme Salgado (salgado) |
| importance: | Undecided → Medium |
| milestone: | none → 10.02 |
| status: | New → Triaged |
| Changed in launchpad-foundations: | |
| status: | Triaged → In Progress |
| Diogo Matsubara (matsubara) wrote Bug fixed by a commit | #2 |
| Changed in launchpad-foundations: | |
| status: | In Progress → Fix Committed |
| tags: | added: windmill |
| Changed in launchpad-foundations: | |
| status: | Fix Committed → Fix Released |
This will also cause your test to fail if the previous one used ensure_login() to login as the same user as your test, and debugging that sort of failure is not fun at all.