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.
Dead bot at http://qa.drupal.org/pifr/test/350618
Dead bot at http://qa.drupal.org/pifr/test/350618
Comments
Comment #1
rfayI retested that one, retested the testbot, logged in and didn't see anything obvious wrong with it. We'll see what happens with reconfirming the testbot.
Comment #2
attiks CreditAttribution: attiks commentedFeel free to kill the test, next one is working.
Comment #3
rfayTestbot #958 went silent and no response for 2 hours. Weird. But it passed tests.
Marking fixed.
Comment #4
jthorson CreditAttribution: jthorson commentedI was going to flag this this morning ... saw that this was a probable testbot-killer.
It's still running on 654, so I'll re-confirmed that as well.
Comment #5
jthorson CreditAttribution: jthorson commentedThis patch is still floating around in the queue ... it's going to have to be manually updated, or a failure forced.
The test does complete successfully, but does not report back properly ... and the PIFR next() call then receives an Internal Server Error response.
Comment #6
rfayLooks like http://drupal.org/node/1734642#comment-6542568 is a testbot killer.
Comment #7
attiks CreditAttribution: attiks commentedCan you stop it, is not feel free to remove that comment.
PS: Is there anything I can do to avoid this?
Comment #8
jthorson CreditAttribution: jthorson commentedTried to reset the test via qa.d.o, and got a WSOD ... reload showed the following error:
Comment #9
rfay@attiks, have you run the relevant tests locally to see what happens? Is there perhaps an infinite loop?
I unpublished the comment. Not sure if that does the job. but I think that the fact that you got another one going OK in that issue has solved the problem.
Comment #10
attiks CreditAttribution: attiks commentedI ran the tests I added, they were green.
Comment #11
jthorson CreditAttribution: jthorson commentedattiks: We should be able to force a failure if we catch the patch actually running on a testbot (i.e. in the first 20 min); otherwise we can solve it via direct db manipulation on qa.d.o.
Comment #12
jthorson CreditAttribution: jthorson commentedMay be related (or not), but I just reset Date 8.x-1.x, which was running for 53 minutes.
Comment #13
rfayI was able to get that test into postponed status with
Trying to set status to 4 (result returned) resulted in a 500 error on that page.
Comment #14
jthorson CreditAttribution: jthorson commentedUnfortunately, postponed is going to be bumped back to 'queued' the next time that the branch test passes.
I'm not sure how the status=4 could cause the Server Internal Error issue, but that's one more piece of data I can use troubleshooting it tonight.
Comment #15
jthorson CreditAttribution: jthorson commentedI messed with this for a while ... no matter what I tried, the test would automatically be re-queued moments later. Also, the site would throw 'plugin [] does not exist' errors (and 'file not found' when trying to load the un-named plugin) ... but I couldn't track down which of the multiple points in the codebase was actually calling the function which threw the error.
Eventually, I gave up and brute-force deleted the test from the qa.d.o database (pifr_test, pifr_environment_status, and pifr_result), which took down qa.d.o for a minute (as the front page still tried to load that particular test due to it being assigned to a testbot) ... disabling and re-enabling that testbot brought the site back, and the spooling 'plugin [] does not exist' errors are gone.
Wish I could have tracked down a root cause ... but that was going to require mucking around and adding debug lines to the production site, which was more than I wanted to take on tonight.