[10:04:20] <dcausse>	 stopping cindy while it gets fixed
[13:03:57] <ebernhardson>	 \o
[13:04:27] <ebernhardson>	 yea still problems with cindy :S overnight looped runs failed in update_general_api and full_text_{browser,advanced}
[13:13:00] <dcausse>	 o/
[13:13:16] <ebernhardson>	 looks like the codfw cluster deploy worked at least
[13:13:32] <dcausse>	 had to restart docker and clean up some things on cindy
[13:13:52] <dcausse>	 and so far I've attempted several runs on your last patch and they were all successful
[13:14:16] <ebernhardson>	 it's a start at least :)  I was hoping i'd be able to get it a point where it can run in a for loop overnight and not fail anything, but maybe that's optimistic :)
[13:16:51] <ebernhardson>	 might be similar to the page loading one though, come from a few tests but typically of the form: AssertionError: I am on Search results: expected 'Search' to equal 'Search results'
[13:16:55] <dcausse>	 yes... there are so many ways it could fail
[13:16:58] <ebernhardson>	 which suggests it hasn't loaded results yet
[13:17:13] <inflatador>	 <o/
[13:17:15] <ebernhardson>	 \o
[13:17:34] <dcausse>	 o/
[13:23:21] <dcausse>	 I think also that indeed "I search for África" -> "I am on a page titled África" clearing missed a step to wait for a page change
[13:24:03] <dcausse>	 separating "I search for X" and "I see/am" was perhaps not ideal 
[13:24:28] <dcausse>	 should have been a single step I think
[13:24:44] <ebernhardson>	 hmm, yea perhaps putting them together would help
[13:25:49] <ebernhardson>	 as for the gerrit comment about a new page, i think we usually end up on a new url but hard to say for sure. Typically we are submitting a form from a random page where the url should change. Similarly we shouldn't perform the same search twice, so url should change on Special:Search. but only probably
[13:25:49] <dcausse>	 the only thing I'm worried is that if youre already on Africa and searching for Africa the page might not change (except for the index.php?search= hop in between)
[13:26:03] <ebernhardson>	 oh, indeed if Special:Random takes you to Africa
[13:26:45] <dcausse>	 I suspect that ( await browser.getUrl() ) !== oldUrl might capture the "index.php?search=" hop?
[13:27:50] <ebernhardson>	 hmm, yea actually thats probably true. Initially it will be the submission, and then the redirect.  I suppose i'm kinda hoping that's handled by document.readyState
[13:28:02] <ebernhardson>	 essentially that once the url changes the readyState should be not-ready, and then wait for it
[13:28:33] <dcausse>	 yes
[13:29:32] <ebernhardson>	 i was surprised to not find much from wdio about waiting for form submission. They basically want you to wait for the new elements or some such
[13:29:40] <dcausse>	 I think it just needs to know whenever we "leave" this current page so that the "I am on a page titled África" does not fail because it's reading the page we searched on initially
[13:29:45] <dcausse>	 yes same
[13:31:27] <dcausse>	 ok re-testing a last time and if it's green we just ship as-is?
[13:32:26] <ebernhardson>	 sure
[13:32:36] <ebernhardson>	 maybe i could just change the page title checks to wait for page title
[13:34:31] <dcausse>	 if we keep separate steps for "I search for" and "I check something" I think it's nice to wait for completion on the "I search for" step
[13:35:02] <ebernhardson>	 hmm, yea that makes sense to keep the action more atomic if possible
[13:35:09] <inflatador>	 .o/
[13:43:42] <dcausse>	 probably me not understanding wdio I don't how you can construct something not prone to race, here I don't see how we can be sure that browser.getUrl() has not already changed before the first iteration on waitUntil
[13:44:07] <ebernhardson>	 dcausse: the idea was to fetch the url before clicking the button
[13:44:57] <dcausse>	 oh you're right, I'm just blind :)
[14:50:45] <inflatador>	 Will not make Weds mtg today
[17:11:09] <dcausse>	 Neriah: we discussed your patch, I think we found a solution, I'll try to comment on this tomorrow :)
[19:24:23] <ebernhardson>	 looks like at least one more relatively frequent itermittent integration failure in smoke.feature. There are probably a few more, but they are much less frequent
[21:38:13] <dcausse>	 ebernhardson: if you're still around I suspect that the instruct hack on the ml connector for codfw was not set
[21:49:24] <inflatador>	 dcausse Ryan and I are still here if we can help w/anything
[21:50:09] <dcausse>	 inflatador: thanks! it's just that results are sometimes weird without this config bits but it's all working
[22:14:08] <dcausse>	 ok should be updated, had to create a new connector/model and update the search_pipeline