HPT tests started failing on D10.1

I'm not reproducing this locally.

Oh, it's because of some changes that were made to the module and tests a few days earlier (July 14). See 📌 Allow upload of zipped hospital price file Fixed

That's probably it. I couldn't run the new tests on d.o prior to committing since there were new binary files being added.

Is this a realpath thing?

The last submitted patch, 6: hpt-failing-tests-3380067-6.patch, failed testing. View results →

That didn't work. The error changed to this in the html output:

Called from GuzzleHttp\Promise\FulfilledPromise::GuzzleHttp\Promise\{closure}() line 48
GET request to: http://php-apache-jenkins-drupal8-contrib-patches-167737/subdirectory/hpt/3
The website encountered an unexpected error. Please try again later.

Symfony\Component\HttpFoundation\File\Exception\FileNotFoundException: The file "" does not exist in Symfony\Component\HttpFoundation\File\File->__construct() (line 36 of vendor/symfony/http-foundation/File/File.php).
Symfony\Component\HttpFoundation\BinaryFileResponse->setFile('', NULL, , 1) (Line: 52)
Symfony\Component\HttpFoundation\BinaryFileResponse->__construct('') (Line: 28)
Drupal\hospital_price_transparency\Controller\HospitalPriceTransparencyController->file(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 592)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 166)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Oh! There's a clue I missed. :)

There's a missing slash:

public:/file.xml

That uri gets built here:

$extract_to_dir = pathinfo($file->getFileUri(), PATHINFO_DIRNAME);
$zip->extract($extract_to_dir, [$zipped_filename]);
$unzipped_file_uri = $extract_to_dir . '/' . $zipped_filename;
$new_file = File::create([
  'uri' => $unzipped_file_uri,
]);

$file->getFileUri() gives public://xml_zip.zip and $extract_to_dir resolves as public:.

So then $unzipped_file_uri gets built with one slash instead of a double slash. That's what needs to be fixed, but I'm not sure exactly the best way.

I think this does it.

Yay!

Here's a bit more test coverage though that focuses on the uri of the extracted zip files.

Phew! I guess some servers can deal with the malformed uri? Or some zip packages can do that? Regardless, this is better. My manual testing was positive as well. Let's commit it.

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