Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
http://qa.drupal.org/pifr/test/240454 was in the queue for way longer than other patches, but suddenly, the patch was skipped and the queue moved on to patches coming after it.
I don't see anything wrong in the logs or with the patch - the only log entry right now is that the patch file was discovered on d.o.
I suspect that the patch was wrongly sent to testbot #664, which is currently in "failed client check" state - although for 19 hours already (whereas the patch was submitted 40 minutes ago). Thus, stuck on a failing testbot client?
Comment | File | Size | Author |
---|---|---|---|
#10 | pifr_fix-permanent-queue_1487002-10.patch | 1.15 KB | jthorson |
Comments
Comment #1
rfayMy usual approach when stuff is in the queue and sitting there is to press the retest button (on qa) on it and that seems to clear it. Jthorson has a theory about how this happens, but we don't have any proof.
I just pressed retest on it, but suspect it's got some pretty serious problems (Can't enable simpletest)
Comment #2
jthorson CreditAttribution: jthorson commentedThere were a couple of D8 paches which seem to cycle and cause issues on the testbot since the testing profile patch went in ... I don't remember this being one of them, so I'll rekick and see how things go today (which should be relatively quiet from a testbot perspective.)
Comment #3
jthorson CreditAttribution: jthorson commentedRetest failed with the same symptom.
Comment #4
brianV CreditAttribution: brianV commentedJust as a note - http://qa.drupal.org/pifr/test/243384 seems to be having this problem. Just in case an example is needed.
Comment #5
30equals CreditAttribution: 30equals commentedYeah, i got a couple of queued tests hanging as well aparentely. Sent test requests yesterday evening (eg sent one at Fri, 03/23/2012 - 21:45:37), without any results and test still in queue.
Comment #6
rfay@30equals Please make sure you refer to the specific test when you post on something like this. Thanks!
Comment #7
30equals CreditAttribution: 30equals commentedsorry about that:
here are the two tests:
post: http://drupal.org/node/857124#comment-5774628
test : http://qa.drupal.org/pifr/test/244134
post: http://drupal.org/node/1479618#comment-5774380
test: http://qa.drupal.org/pifr/test/244054
Comment #8
jthorson CreditAttribution: jthorson commentedWhen this occurs, you can click through to the /pifr/test/(test_id) page on qa.drupal.org to see the result of your patch ... it does get tested, but it just seems that it doesn't get updated in all the right places.
Theory: When D7/D8 head branch tests are executed, all other queued tests are placed in a 'postponed' status. I'm wondering if the ones which get stuck in the 'queued' listing might be the tests which were under test and/or completed while the D7/D8 head tests kicked in.
Comment #9
jthorson CreditAttribution: jthorson commentedLooking through the code, my theory in #7 appears to be on the right track.
A test which has been handed off to a testbot is still considered 'queued', and when a branch test is ran (and fails), all queued file tests for that branch get bumped to 'postponed'. When a branch test is ran and passes, all postponed tests for that branch get marked as 'queued'.
Because the logic doesn't take into account advisory environments, a test can be marked as 'postponed' in the time between when a failed coder test completes and a passing branch test completes.
The code which updates a test status to 'result' to indicate it's completed testing is wrapped in a 'if status = queued' check. Given the statement in the previous paragraph, there is thus a window of time during each HEAD test where any file tests which are simultaneously running will not get updated properly.
I believe that a potential quick solution would be to update the 'if queued' check in pifr_server_test_result() to 'if queued or postponed' ... but need to work on being able to recreate the problem on qa.scratch before I can properly test the solution.
Comment #10
jthorson CreditAttribution: jthorson commentedUpon further thought, I would need at least three different testbots all running on qa.scratch simultaneously in order to reproduce this bug, and that's just more effort that it's worth for such a simple patch.
Will post here for a few days before committing into 6.x-2.x.
Comment #11
SilviuChingaru CreditAttribution: SilviuChingaru commentedHanging tests for me too:
#1492626: "Cart Items" triggers dont work
post: http://drupal.org/node/1492626#comment-5832004
test: http://qa.drupal.org/pifr/test/251014
#1514756: Stock transaction should be more flexible through Rules
post: http://drupal.org/node/1514756#comment-5826676
test: http://qa.drupal.org/pifr/test/250534
post: http://drupal.org/node/1514756#comment-5827376
test: http://qa.drupal.org/pifr/test/250584
post: http://drupal.org/node/1514756#comment-5828108
test: http://qa.drupal.org/pifr/test/250739
#1413372: Admin order shipping method not set and order data reset when shipping quote applied to order
post: http://drupal.org/node/1413372#comment-5829210
test: http://qa.drupal.org/pifr/test/250779
Comment #12
jthorson CreditAttribution: jthorson commentedfiftyz: The tests you listed are legitimately 'postponed', and will be until the branch test (http://qa.drupal.org/pifr/test/132134) passes 100% of tests.
We can't test a patch and tell if it introduces a failure or not, unless we start with a 'known good' branch ... in this case, the branch is 'known NOT good'.
Comment #13
longwave@jthorson: What if a patch is designed to fix the failing branch test? In this case I am not sure why the one test case started failing, when it has been there for some time and previously had passed. The test also passes locally. It does involve writing to the local filesystem (in the public files directory), but I'm not sure what to do to fix it (although the entire test has been rm'd for now so the branch passes again).
Comment #14
jthorson CreditAttribution: jthorson commentedIf a patch is designed to fix the failed branch, your best bet is to test it locally, and commit based on whether the local testing passes.
Comment #15
longwaveBut as I said, the tests do pass locally, and used to pass on testbot; they only started failing there recently.
Comment #16
rfayThe Ubercart 7.x-3.x is in fact passing right now, All the patches listed in #11 are also now passing. We're back to #10 CNR.
Comment #17
jthorson CreditAttribution: jthorson commentedLongwave ... If you have issues with a specific branch/test, please open a dedicated issue.
Comment #18
jthorson CreditAttribution: jthorson commentedPatch committed to 6.x-2.8 ... will leave open for a couple days to validate whether the fix was successful.
Comment #19
sunThe fixed status does that automatically for you ;)
Comment #20
hass CreditAttribution: hass commentedhttp://qa.drupal.org/pifr/test/256814
Comment #21
rfay@hass, that one's postponed because the branch tests are broken. http://qa.drupal.org/pifr/test/235884