Return value must be of type Symfony\Component\HttpFoundation\StreamedResponse

I'm not getting this in the current dev version, though the code is unchanged. I'll reopen if necessary.

In the course of troubleshooting issue #3355294 I noticed that I'm getting this error again. It's not fatal, just appears in the logs. I still can't figure out the cause. Maybe the traceback will help.

TypeError: Drupal\views_pdf\Plugin\views\display\PDF::buildResponse(): Return value must be of type Symfony\Component\HttpFoundation\StreamedResponse, Drupal\Core\Cache\CacheableResponse returned in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 145 of /home/xxxxxx/public_html/web/modules/contrib/views_pdf/src/Plugin/views/display/PDF.php).

#0 /home/xxxxxx/public_html/web/core/modules/views/src/Routing/ViewPageController.php(56): Drupal\views_pdf\Plugin\views\display\PDF::buildResponse('id_card', 'pdf_5', Array)
#1 [internal function]: Drupal\views\Routing\ViewPageController->handle('id_card', 'pdf_5', Object(Drupal\Core\Routing\RouteMatch))
#2 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#3 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#4 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#5 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#6 /home/xxxxxx/public_html/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#7 /home/xxxxxx/public_html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#8 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /home/xxxxxx/public_html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /home/xxxxxx/public_html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /home/xxxxxx/public_html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /home/xxxxxx/public_html/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /home/xxxxxx/public_html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#20 {main}

I too am seeing this (in the 3.0.0-alpha10 version). I'm also seeing issue 🐛 Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of modules/contrib/views_pdf/src/Plugin/views/display/PDF.php). Active and I wonder whether this issue (3426719) is the root cause of 3355295? Why do I wonder this? Because clearing the caches provides relief for 3355295, and the error message for this issue includes reference to Drupal\Core\Cache\CacheableResponse. May be a Red Herring, but I thought it worth mentioning.

I'm still seeing this so removing the draft flag. I see that the function name currently specifies "StreamedResponse" but four lines later, when the $response variable is initiated, it says "CacheableReponse." Does that explain the error?

$response = new CacheableResponse('', 200);

Drupal 10.3.10
PHP 8.1.31
Views PDF 3.0.0-alpha10+3-dev

I've manually applied the change in MR !9 to my site running:

Drupal 10.3.10
PHP 8.1.30
Views PDF 3.0.0-alpha10

The error reported above is no longer seen, so this issue seems to be fixed, thank you.

To test my conjecture that this issue might be the root cause of issue 🐛 Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of modules/contrib/views_pdf/src/Plugin/views/display/PDF.php). Active I set the caching of the PDF View back to "Tag based" - I had previously changed it to "None", the known work around for 3355295. I find that:

First load of the PDF works fine, with no reporting of the error giving rise to this issue (3426719).
Second attempt to load the PDF causes a blank page to open. Prior to introducung the MR !9 change I was seeing a "The website encountered an unexpected error. Try again later." on-screen message. Also, the warnings and error previously reported in the log are no longer present with the MR !9 changes in place. As before, clearing the caches, allows the PDF to load on a second attempt.

It is now clear to me that these two issues are related and I am, therefore, flagging them as such. And whilst there is a work around for 3355295 it would be nice to identify a fix that obviated the need for it - but with no on-screen message and nothing in the log, there's maybe not much to go on.

I've just added a comment to 🐛 Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of modules/contrib/views_pdf/src/Plugin/views/display/PDF.php). Active noting that with caching turned on, PDF pages on a Drupal 7 site that I have will only load once.

By default, caching had been turned off on that site, and there had been no issues with pages loading more than once. I tried turning caching on, just to see what would happen. The results then (with Views PDF 7.x-3.1) are similar to what I am seeing now with Views PDF 3.0.0-alpha10.

I've suggested that we need a view from a maintainer as to how to proceed as it would be good to move Views PDF 3.x beyond an alpha release.

I am sorry to report that I have identified an issue with MR !9. I have previously reported against issue 🐛 Error: Call to a member function Output() on null in Drupal\views_pdf\Plugin\views\display\PDF::buildResponse() (line 141 of modules/contrib/views_pdf/src/Plugin/views/display/PDF.php). Active that the proposed fix of setting caching (in the View which generates the PDF) to None (to resolve the issue of being able to load a PDF only once) was only partially effective as it didn't work for anonymous users. I have now found that if I revert MR !9 that is no longer the case, as an anonymous user I can load the PDF multiple times.

I've also found that, with MR !9 in place, refreshing the browser tab containing the generated PDF causes the PDF to disappear. If the PDF browser tab is refreshed with MR !9 reverted, the PDF regenerates as expected.

With MR !9 reverted I can find no fault with the PDF generation but, of course, the error message reappears in the log.

Having identified these issues with MR !9 I feel obliged to set this issue back to needs work.

I don't know whether this might help with resolving the issue but here are some other findings of mine - note that in my setup, the PDF is generated in a browser tab separate from that displaying the node from which the PDF is built - that tab also displays the link to the View which generates the PDF :

1. With caching set to None and MR !9 applied I can, as an anonymous user load the PDF multiple times, but only provided that between load attempts I refresh, in my browser, the tab displaying the source node.
2. With Tag based caching and MR !9 applied, I can, as an authenticated user, load the PDF multiple times, but only provided I refesh the browser tab, as above, between attempts to load the PDF. And in this case, the browser refreshing does not work for an anonymous user.

I've also noted that in the Drupal 7 version of my site, caching within the PDF generating View is set to None by default. Turning caching on, introduces the "one time only" PDF generation issue. So that issue is not new. Is the answer for Views PDF 3 to abandon any attempt to introduce caching? And instead advise users that caching within the PDF generating View should be turned off?