"Session has not been set" error on drush cron

Created on 4 October 2023, about 1 year ago
Updated 1 February 2024, 11 months ago

When cron runs via drush, it fails with the following:

Symfony\Component\HttpFoundation\Exception\SessionNotFoundException: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of /var/www/vendor/symfony/http-foundation/Request.php).

It does not seem to occur when cron is run via the interface.

πŸ’¬ Support request
Status

Fixed

Version

4.1

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States greatmatter

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

Comments & Activities

  • Issue created by @greatmatter
  • πŸ‡ΊπŸ‡ΈUnited States darrell_ulm

    Seeing this error recently for Drupal 10 branch when running
    drush sapi-i
    for search_api_solr

  • πŸ‡ΊπŸ‡ΈUnited States greatmatter

    Is this solvable?

  • Status changed to Postponed: needs info about 1 year ago
  • πŸ‡©πŸ‡ͺGermany gbyte Berlin

    How do you know this is a simple_sitemap issue? Can you provide the full stack trace?

  • πŸ‡ΊπŸ‡ΈUnited States greatmatter

    No--I don't have a stack trace, but because the site is in prod, I don't have a good way of debugging it that deeply. I'll check out our other sites and let you know if I see anything that points to Simple XML sitemap...

  • Status changed to Active about 1 year ago
  • πŸ‡©πŸ‡ͺGermany gbyte Berlin
  • πŸ‡ΊπŸ‡ΈUnited States scottsawyer Atlanta

    Same issue, freshly upgraded to D10, indexing the site via UI. Looks like while the batch was running cron also started running, then these messages started appearing.

    Type: simple_sitemap
    User: Anonymous
    Severity: Error
    Message: Symfony\Component\HttpFoundation\Exception\SessionNotFoundException: Session has not been set. in Symfony\Component\HttpFoundation\Request->getSession() (line 727 of /code/vendor/symfony/http-foundation/Request.php).

    I am also seeing similar errors with Type: search_api.

    Maybe it's related to πŸ› Check for session before calling Request::getSession() Fixed ?

  • πŸ‡ΊπŸ‡ΈUnited States scottsawyer Atlanta

    I am increasing the priority to Major because it seems that an existing site map is deleted as part of the cron job, but then its unable to regenerate, leaving the site with 404 errors when there is an attempt to retrieve the sitemap.

    I am not setting to critical, because the sitemap can be regenerated from the UI (drush fails, even though it reports completed). However, this is not a great solution.

  • πŸ‡©πŸ‡ͺGermany gbyte Berlin

    This is still a support request and not a bug report, so changing back the priority. I have the module running on several servers and I'm not encountering this (anecdotal evidence, I know)

    This sounds like an exception I used to get when having a space character before the opening php tag, but I might be misremembering.

    In any case, I need a full stack trace to debug this. @greatmatter Maybe you're able to clone the environment and reproduce the issue along with a trace?

  • πŸ‡ΊπŸ‡ΈUnited States scottsawyer Atlanta

    I just wanted to follow up and report my findings. For me, and likely others, this is due to a change in Symfony\Component\HttpFoundation\Request, which, in current versions of Symfony ,throws the exception if the session can not be found when calling ->getSession(). I found an instance in one of my custom modules, and changed the code to first check ->hasSession() before calling ->getSession(), and the errors go away immediately. Likely the custom code was invoked during cron and drush operations, and causing the exception. I grepped this module for '->getSession()' and I could only find it in the tests, so simple_sitemap is definitely not the culprit.

  • Status changed to Closed: outdated 11 months ago
  • πŸ‡ΊπŸ‡ΈUnited States greatmatter

    @scottsawyer - Thank you--this did the trick--found a custom module doing just that. I owe you a beer...

  • Status changed to Fixed 11 months ago
  • πŸ‡©πŸ‡ͺGermany gbyte Berlin

    Setting to fixed, since it's a solved support request.

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

Production build 0.71.5 2024