Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
https://www.drupal.org/pift-ci-job/861269 shows a random failure.
Let's prevent this from happening!
Proposed resolution
Add a waitForText() method, and use it.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#12 | 2937073-field_block-12.patch | 2.54 KB | savkaviktor16@gmail.com |
#7 | 2937073-field_block-7.patch | 2.57 KB | tim.plunkett |
#7 | 2937073-field_block-7-pass.patch | 3.18 KB | tim.plunkett |
#7 | 2937073-field_block-7-random-fail.patch | 623 bytes | tim.plunkett |
#5 | 2937073-field_block-5-interdiff.txt | 2.38 KB | tim.plunkett |
Comments
Comment #2
tim.plunkettComment #3
tedbowYou could do this in 1 line
$this->assertNotEmpty($assert_session->waitForText('The block configuration has been saved.'));
You wouldn't need to call
pageTextContains()
then.Comment #5
tim.plunkettThat CSS trick is nice, but not robust enough to rely on.
Comment #6
tedbowThis looks good. The new
\Drupal\FunctionalJavascriptTests\JSWebAssert::waitForText()
uses the same regex logic as existing\Behat\Mink\WebAssert::pageTextContains()
This should fix if the submit on the previous lines were slow down by testbot.
@tim.plunkett Could we get a patch that runs the updated test only x30(not sure if we can get more without timeout) and 1 that runs the current test only 30x? This could prove that 1 fails more often. I know they may likely both come back green but worth a shot.
See here for changes needed to
run-tests.sh
to run a single test mutiple times https://www.drupal.org/files/issues/2830485-142-100x.patchHmm that did 100x for some reason I thought it would time out. Could try that.
Comment #7
tim.plunkettReuploading the clean patch for commit, along with the hacked ones to try to prove the randomness is gone
Comment #8
tim.plunkettComment #9
borisson_There are no failures in #7, but the change does look good. Should we try this with more passes on the fragile test?
Comment #10
tim.plunkettComment #12
savkaviktor16@gmail.com CreditAttribution: savkaviktor16@gmail.com at Skilld commentedRe-rolled against 8.7.x
Comment #13
tim.plunkettThanks for the reroll. As I wrote the patch, someone else should perform the final review for RTBC.
Comment #14
Kristen PolThe code looks fine to me. I don't think there is any way to manually test this. Since tests are passing, marking RTBC.
Comment #16
xjmSo according to the IS this caused a random test failure, but I haven't gotten an email about it failing since April, so looks like a low fail rate. Promoting to major for that reason (instead of critical).
Comment #17
xjmFixing issue credit.
Normally for a random test failure I'd want to see an illustration that the random fail was fixed via bulk test runs (where the bulk test run of unpatched HEAD showed consistent fails by deliberately slowing the page down or such), but since the fail rate on this appears to be very low, it might be infeasible. Furthermore, according to @tim.plunkett:
Comment #20
xjmCommitted to 8.7.x and cherry-picked to 8.6.x. Thanks!