The session is not being updated.

I created an MR. I'm not sure if it's the best solution, but it solves the problem until someone can fix it properly. I'm available to work on this ticket if anyone can help me figure out a permanent solution to the issue.

My expectation is the opposite—the session should end.

Thank you, charlliequadros. This solution worked for me, adding this change the session is being updated in each request.
Hi cilefen, Is your session never ending?

The session should end after gc_maxlifetime. No?

Hi @cilefen

In Drupal version 10.2.7, the user's session was updated with each request, meaning that as long as the user interacted with the site, the session time was refreshed, preventing it from expiring during use. However, after updating to version 10.3.0, this behavior changed: the session time is no longer updated. So, if the timeout is reached, the session will be automatically closed, regardless of what the user is doing, such as during content creation or editing, for example. What's not working after the update is the session time being refreshed while the user is interacting with the site.

As I mentioned my expectation is the opposite of yours.

Anyway, perform a git bisect on a Git working copy of Drupal core to understand which commit changed this.

Hi @cilefen,

I followed your suggestion to identify when the issue was introduced.

This issue arose during the resolution of this issue. https://www.drupal.org/project/drupal/issues/3414287 📌 Avoid reading session from the database multiple times during a request Needs work

I couldn’t determine which call was removed to avoid two database requests. Was it "$request->getSession()->save();" or "$this->session->start();

Hello charlliequadros and cilefin,

After some investigation, here is my conclusion.

This change is related to the big pipe, here ( https://www.drupal.org/project/drupal/issues/3414287 📌 Avoid reading session from the database multiple times during a request Needs work ) is the Drupal issue. So checking this, the changes between Drupal versions 10.2.7 and 10.3.0 in BigPipe were changes to implement enhance performance and security in the delivery of dynamic content on web pages. However, might be affecting how the session is managed, particularly concerning the SSESS cookie's update timing.

In Drupal 10.2.7, BigPipe handled session management by reopening the session during the rendering of placeholders and then closing it afterward. This ensured that the session's expiration time was updated as content was progressively delivered to the user. However, in Drupal 10.3.0, the changes of these pre- and post-rendering tasks may be disrupting the regular update process of the SSESS cookie.

These changes could be preventing the session from being reopened or correctly managed during placeholder rendering, leading to issues with the SSESS cookie's expiration time.

If I revert the changes made here (https://git.drupalcode.org/project/drupal/-/merge_requests/6441/diffs#6c...) in the files BigPipe.php and BigPipeResponse.php, it works as before.

stack used:
- domain module (with domain_entity on) https://www.drupal.org/project/domain →
- drupal/jsonapi_extras https://www.drupal.org/project/jsonapi_extras →
- webforms
- Webforms Rest https://www.drupal.org/project/webform_rest →

and when I call any REST endpoint, for example webform_rest//fields?_format=json
I get "No route found for the specified format html. Supported formats: json, XML."

The stack looks like below

array(
    0 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Routing\\Router.php',
        'line' => 280,
        'function' => 'filter',
        'class' => 'Drupal\\Core\\Routing\\RequestFormatRouteFilter',
        'type' => '->',
    ),
    1 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Routing\\Router.php',
        'line' => 126,
        'function' => 'applyRouteFilters',
        'class' => 'Drupal\\Core\\Routing\\Router',
        'type' => '->',
    ),
    2 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Routing\\Router.php',
        'line' => 103,
        'function' => 'matchRequest',
        'class' => 'Drupal\\Core\\Routing\\Router',
        'type' => '->',
    ),
    3 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Path\\PathValidator.php',
        'line' => 161,
        'function' => 'match',
        'class' => 'Drupal\\Core\\Routing\\Router',
        'type' => '->',
    ),
    4 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Path\\PathValidator.php',
        'line' => 122,
        'function' => 'getPathAttributes',
        'class' => 'Drupal\\Core\\Path\\PathValidator',
        'type' => '->',
    ),
    5 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Path\\PathValidator.php',
        'line' => 89,
        'function' => 'getUrl',
        'class' => 'Drupal\\Core\\Path\\PathValidator',
        'type' => '->',
    ),
    6 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Url.php',
        'line' => 427,
        'function' => 'getUrlIfValidWithoutAccessCheck',
        'class' => 'Drupal\\Core\\Path\\PathValidator',
        'type' => '->',
    ),
    7 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Url.php',
        'line' => 319,
        'function' => 'fromInternalUri',
        'class' => 'Drupal\\Core\\Url',
        'type' => '::',
    ),
    8 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Url.php',
        'line' => 221,
        'function' => 'fromUri',
        'class' => 'Drupal\\Core\\Url',
        'type' => '::',
    ),
    9 => array(
        'file' => '.\\web\\modules\\contrib\\domain_entity\\src\\HttpKernel\\DomainEntitySourcePathProcessor.php',
        'line' => 147,
        'function' => 'fromUserInput',
        'class' => 'Drupal\\Core\\Url',
        'type' => '::',
    ),
    10 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\PathProcessor\\PathProcessorManager.php',
        'line' => 108,
        'function' => 'processOutbound',
        'class' => 'Drupal\\domain_entity\\HttpKernel\\DomainEntitySourcePathProcessor',
        'type' => '->',
    ),
    11 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Routing\\UrlGenerator.php',
        'line' => 388,
        'function' => 'processOutbound',
        'class' => 'Drupal\\Core\\PathProcessor\\PathProcessorManager',
        'type' => '->',
    ),
    12 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Routing\\UrlGenerator.php',
        'line' => 297,
        'function' => 'processPath',
        'class' => 'Drupal\\Core\\Routing\\UrlGenerator',
        'type' => '->',
    ),
    13 => array(
        'file' => '.\\web\\core\\lib\\Drupal\\Core\\Render\\MetadataBubblingUrlGenerator.php',
        'line' => 105,
        'function' => 'generateFromRoute',
        'class' => 'Drupal\\Core\\Routing\\UrlGenerator',

As you see DomainEntitySourcePathProcessor.php invokes Url::fromUserInput() and what he tries to do is basically detect if user has access to access this route in terms of Domain Entity logic. If for example I instantly return $path value form DomainEntitySourcePathProcessor::processOutbound() not doing any logic - then all works, no error. But I cant do that, the logic must happen.

And what happens later is that Symfony\Component\HttpFoundation\Request is recreated multiple times. But its constructor or factories does not care about _format value passed in any manner, it must be manually set, otherwise Request::duplicate() method must be used.

I have examined all the chain few times (this problem I observe for 10 months and its time to finally solve it, client needs that).
And my suggestion is to do change in web\core\lib\Drupal\Core\Routing\Router.php

  public function match($pathinfo): array {
    $request = Request::create($pathinfo);
    $request->getRequestFormat(\Drupal::request()->getRequestFormat()); // ADD THIS LINE

works good, solves the problem and nothing broken.

I will publish the patch soon.

P.S. I have a feeling like the problem should be solved on some level higher, maybe where getUrlIfValidWithoutAccessCheck() should exist option for full path with ?query support in URL or maybe version with full request. But I cant formulate that right now

The session should never be written on every single request, we have specific logic to prevent this

See WriteSafeSessionHandler::write().

What behaviour do you get with big pipe disabled - e.g. does the session timestamp get updated there when it doesn't for big_pipe?

Testing locally with big_pipe enabled, when I first visit the site, my session timestamp gets update, then I click around a bit, and it doesn't get updated for a while, but then if I try again ~6-7 minutes later, the timestamp gets updated again. This is what I'd expect to happen.

This should be the same with or without big_pipe too - or at least that was the intention of 📌 Avoid reading session from the database multiple times during a request Needs work .

It's possible there's a bug somewhere, but please clarify the steps to reproduce if you can - the session should be updated every few minutes, not every request.