Fails on testbot, works locally under subdir drupal using run-test.sh [#2598720]

I have a patch for Examples 8.x-1.x, #2102651: Port file_example module to Drupal 8, testing patch file-example-2102651-torenware-v3.patch.

I'm looking at the failure at:

https://www.drupal.org/pift-ci-job/58806.

It works locally under the SimpleTest UI and via run-test.sh.

My set up:

A Vagrant Ubuntu 14.04 LTS virtual.
Provisioned via Drupal-VM (a popular ansible based provisioner.
Drupal files at /var/www/drupal.
Drupal 8.0.x, HEAD from today.

I've tried the following:

I changed my apache2 settings so that DOCUMENT_ROOT is now /var/www, so that my apparent URL is http://192.168.88.88/drupal/.
Running via SimpleTest UI at http://192.168.88.88/drupal/admin/config/development/testing, works flawlessly, no fails.

Running run-test.sh as user "vagrant" from directory /var/www/drupal/core with the following parameters:

php scripts/run-tests.sh --non-html --verbose --url http://192.168.88.88/drupal/ --class '\Drupal\file_example\Tests\FileExampleTest'

This also works fine; no fails.

Since this covers the "usual suspects", I'm at a loss to explain this. The only thing I can think of is that the module is doing one unusual thing. To demonstrate stream wrappers, it implements a stream wrapper that puts a file system over the $_SESSION variable. The fail in the test seems happen when the test tries to download a "file" using a URL that resembles what's used for the private: scheme in Drupal:

debug: [Debug] Line 128 of modules/examples/file_example/src/Tests/FileExampleTest.php:
Name of output file: session://jiuEV9Zwhb/p4df8vVG5oxNjsqC5WEhTR6jf88PBr.txt

fail: [Other] Line 138 of modules/examples/file_example/src/Tests/FileExampleTest.php:
File contents matched.
Value 'xQbKrpG96bU6Bs5rnBhDuxYDQ8ivRw' is equal to value '

Not Found
The requested URL /checkout/example/file_examples/files was not found on this server.

'.

If I had to guess, the URI being referenced was:

/checkout/example/file_examples/files?file=jiuEV9Zwhb/p4df8vVG5oxNjsqC5WEhTR6jf88PBr.txt

This may seem a little hinkey, but this works in the configurations I listed above. And the URI looks correct to me.

Is there something in your set up that would barf if we did something like this to $_SESSION? Or is there some other reason the test failed?

Much thanks.

Comments

Comment #1

22 October 2015 at 02:56

Torenware created an issue. See original summary.

Comment #2

Torenware commented 22 October 2015 at 04:14

Two other theories:

The URL at the failed link /checkout/example/file_examples/files does not mention that there was a GET string. I'm not where the message was generated, but if the GET string was not passed on to the server, I'd guess that the router would return a 404. Could it be stripped by your set up?
It's possible that the server you use for the Drupal instances has security at the web server level, and it looked at the generated URL and it figured my module was Up. To. No. Damn. Good. Causing it to either defang the URL, or simply block it before it even hit the Drupal instance.

If either of these cases hold, anything you can tell me so I can rewrite the module to make the Testbot happier, much obliged.