Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
None
-
-
pannonian
Description
This is 100% repeatable for me.
1. Start ath running in dev mode.
2. Run nightwatch src/test/js/failing.js
3. If you want to see it again, you MUST restart ath.
You will see on step 5 it redirects to run '3' when it should be '2'.
HOWEVER for subsuequent runs of failing.js, it works properly. It's only on the first run of failing.js after the ath is started. No idea what is going on here and I havent replicated it outside of ATH.
Attachments
Activity
Yes when it fails, it is when re-run has opened the incorrect run. I believe this is showing up a real bug. I don't think this stops the ATH however as it does retry things automatically
kzantow cliffmeyers any ideas on this?
Will have to debug it, but we are relying on the "expectedBuildNumber" that's returned from the REST API when we execute the run. We should start there and make sure the value is correct.
I spent some time reproducing. I can confirm that the back end is sending back the wrong expectedBuildNumber, however it isn't clear when.
I am lowering priority:
- This is a bug, but likely not with front end
- Seems related to some race condition when you run the ATH with really fast clicking
- Can't be seen in the wild (believe me, I tried, with many combinations including executor starvation)
- Doesn't seem to ever fail the ATH due to the built in retry
We tried to reproduce this but we were not able to find it again. Please reopen if this pops up again.
Yes I can see this too - not always first time, and doesn't always succeed the second time either, but that is generally a reliable way to see it. Its def not opening the right thing on re-run always.