\Drupal::messenger() changed behaviour between Drupal 10.2.7 and Drupal 10.3.0

Created on 30 June 2024, 5 months ago

I had following code in the exception handling of a form build function ($e is a Throwable):

        $error = $e->getMessage();
        $message = Markup::create($error);
        \Drupal::messenger()->addError($message);
        $url = Url::fromRoute('<front>');
        $response = new RedirectResponse($url->toString());
        $response->send();

If there was an error Drupal would jump to the front screen and the message would display there. This is how it worked in Drupal 10.2.7, and the behaviour was also checked in our behat tests. After only upgrading drupal/core-recommended to 10.3.0 that behaviour changes.

As it works in Drupal 10.3.0, is that you don't see anything on the "front" screen after the redirect, but when you go to the same form that triggered the error the message will appear.

🐛 Bug report
Status

Active

Version

10.3

Component
Other 

Last updated about 16 hours ago

Created by

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @sboden
  • Could you please perform a git bisect on a working copy of Drupal Core to find the commit that changed the behavior? This operation will find the commit quickly.

  • To do this use 10.2.7 as the "good" commit and 10.3.0 as the "bad" commit.

  • I did a git bisect and end up at this one:

    522404706e440106fe7e5d382ce018b0f89637d4 is the first bad commit
    commit 522404706e440106fe7e5d382ce018b0f89637d4
    Author: Alex Pott <alex.a.pott@googlemail.com>
    Date:   Thu Feb 22 13:05:24 2024 +0000
    
        Issue #3414287 by catch, longwave: Avoid reading session from the database multiple times during a big pipe request
    
        (cherry picked from commit 213906e2867ddf6187bb140a3002db2c1144ab92)
    
     .../Core/Session/ResponseKeepSessionOpenInterface.php    | 16 ++++++++++++++++
     core/lib/Drupal/Core/StackMiddleware/Session.php         |  3 ++-
     core/modules/big_pipe/src/Render/BigPipe.php             | 12 ------------
     core/modules/big_pipe/src/Render/BigPipeResponse.php     |  3 ++-
     .../OpenTelemetryAuthenticatedPerformanceTest.php        |  3 +--
     .../src/FunctionalJavascript/StandardPerformanceTest.php |  4 ++--
     6 files changed, 23 insertions(+), 18 deletions(-)
     create mode 100644 core/lib/Drupal/Core/Session/ResponseKeepSessionOpenInterface.php
    
  • I tried disabling bigpipe but that does not make it revert to the previous behaviour.

  • 🇬🇧United Kingdom longwave UK

    Generally you should not call $response->send() directly, instead you should be returning the redirect from a controller and allowing Drupal to process the response.

  • This is part of code for a Form. An API call fails and in that case I want to go back to with an error message on .

    The new behavior is that you go to but the error message doesn't show there, the error does show when you go to the form on which the exception occurred/where the error was added.

    It's not breaking Drupal, but it's breaking the flow of a Drupal application when that depends on the old behavior of status messages.

  • 🇪🇸Spain ady1503
      \Drupal::messenger()->addStatus(t('Dear %user, Welcome to our %site',['%user' => 'admin', '%site' => 'Drupal Learn']));
      $response = new RedirectResponse($url->toString());
      $request = \Drupal::request();
      // Save the session so things like messages get saved.
      $request->getSession()->save();
      $response->prepare($request);
      // Make sure to trigger kernel events.
      \Drupal::service('kernel')->terminate($request, $response);
      $response->send();
    

    source: https://blog.birk-jensen.dk/drupal-http-redirection-from-anywhere
    https://www.drupal.org/node/2023537

    Works form mi for same problem with messenger after update to Drupal 10.3.0

    Hope help.

  • When you need to redirect in a function that has $form_state, you can use $form_state->setRedirect(): that works as before.

    I would suggest to close the bug as chances of the root cause being reverted seem slight, and there is a viable workaround, either using $form_state->setRedirect() or the solution from #9.

    But it does suck that it breaks existing functionality.

  • Status changed to Postponed: needs info 12 days ago
  • 🇳🇿New Zealand quietone

    The last comment suggests that this issue is closed.

    To allow others an opportunity to respond I am setting this the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

Production build 0.71.5 2024