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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rfay’s picture

My 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)

jthorson’s picture

There 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.)

jthorson’s picture

Retest failed with the same symptom.

brianV’s picture

Just as a note - http://qa.drupal.org/pifr/test/243384 seems to be having this problem. Just in case an example is needed.

30equals’s picture

Yeah, 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.

rfay’s picture

@30equals Please make sure you refer to the specific test when you post on something like this. Thanks!

30equals’s picture

jthorson’s picture

When 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.

jthorson’s picture

Looking 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.

jthorson’s picture

Status: Active » Needs review
FileSize
1.15 KB

Upon 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.

jthorson’s picture

fiftyz: 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'.

longwave’s picture

@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).

jthorson’s picture

If 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.

longwave’s picture

But as I said, the tests do pass locally, and used to pass on testbot; they only started failing there recently.

rfay’s picture

The 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.

jthorson’s picture

Longwave ... If you have issues with a specific branch/test, please open a dedicated issue.

jthorson’s picture

Status: Needs review » Reviewed & tested by the community

Patch committed to 6.x-2.8 ... will leave open for a couple days to validate whether the fix was successful.

sun’s picture

Status: Reviewed & tested by the community » Fixed

The fixed status does that automatically for you ;)

hass’s picture

Status: Fixed » Needs work
rfay’s picture

Status: Needs work » Fixed

@hass, that one's postponed because the branch tests are broken. http://qa.drupal.org/pifr/test/235884

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.