## Problem/Motivation AguiChatController::createAgentStreamResponse() calls AiAssistantApiRunner::startSession() unconditionally near the top of its StreamedResponse callback: // docroot/modules/contrib/agui/src/Controller/AguiChatController.php // Re-open the session for TempStore operations during process(). // After kernel.response closes the session, subsequent TempStore calls // need an active session to resolve the anonymous owner key. $this->aiAssistantApiRunner->startSession(); AiAssistantApiRunner::startSession() (in ai_assistant_api) calls Drupal's SessionManager::start() — i.e. native session_start() — whenever the active AI Assistant's "Allow History" setting is anything other than none (the form's own default value is 'session', so this fires for most assistants out of the box). Calling session_start() mid-way through a long-running StreamedResponse callback, well after Drupal's normal request/session lifecycle has already progressed through kernel.response, registers PHP's own native shutdown handler for session_write_close(). That handler runs at true PHP process shutdown — after DrupalKernel::terminate() has already popped the current request off the RequestStack. When it fires in that state, Drupal core's Drupal\Core\Session\SessionHandler::doWrite() calls: $request = $this->requestStack->getCurrentRequest(); // NULL ... 'uid' => $request->getSession()->get('uid', 0), // fatal: Call to a member function getSession() on null ...and PHP fatals with: Error: Call to a member function getSession() on null in Drupal\Core\Session\SessionHandler->{closure:Drupal\Core\Session\SessionHandler::doWrite():69}() (line 74 of /var/www/html/docroot/core/lib/Drupal/Core/Session/SessionHandler.php) ## Steps to reproduce 1. Configure an AI Assistant with "Allow History" set to Session (or Session (Same thread on reload)) — the form default. 2. Trigger a condition that makes the chat request fail fast, before any streamed content chunks are sent (in our case, an ai_metering quota-exceeded exception thrown from a PreGenerateResponseEvent subscriber; a similar effect is plausible from any subscriber/validator that throws early). 3. Observe a PHP fatal (Call to a member function getSession() on null) in the web server/PHP logs, originating from SessionHandler::doWrite(), even though the chat UI itself may show a normal RUN_ERROR message. ##Proposed resolution A couple of options, not mutually exclusive: 1. In AguiChatController, avoid starting/touching the session this way mid-stream, or defer/guard it so it can't leave a dangling native session-shutdown registration when the callback exits early via an exception. 2. Consider whether startSession()/the TempStore re-open dance is needed on every request regardless of history mode, versus only when shouldStoreSession() is true, and only right before it's actually needed (closer to where TempStore calls happen) rather than unconditionally up front. 3. Independently, Drupal\Core\Session\SessionHandler::doWrite() in core could guard against $this->requestStack->getCurrentRequest() returning NULL rather than fataling — but that's core's responsibility, filed here mainly as context since agui's usage pattern is what exposes it.