SessionManager::isStarted() returns TRUE even after session_write_close() has been called

Let's see what happens.

While testbot only shows 1 failing test case, that failure/error effectively means all web tests - but only when executed through the Simpletest UI.

1. The non-interactive installer throws PHP notices: "Ignoring call to session_start(), session is started already."
2. The session of the UI test runner leaks into all web tests.
3. We currently "disable" session saving in TestBase::prepareEnvironment().
4. The session_manager service is persisted. However, the service persistence facility only applies to DrupalKernel::updateModules() — it does not apply to complete replacements of DrupalKernel.
5. After the SessionManager has been re-instantiated from scratch for the installer kernel, install_bootstrap_full() tries to initialize() the session — but it is initialized already.

Attached patch attempts to

1. Properly write + close the current session in TestBase::prepareEnvironment().
2. Restore it in TestBase::restoreEnvironment().

That apparently works... until the restore, which blows up with this exception:

Uncaught exception thrown in session handler.

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: failed to instantiate user-supplied statement class: SELECT 1 AS expression
FROM 
{sessions} sessions
WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ); Array
(
[:db_condition_placeholder_0] => jGHUKbKnm2LIgdt5tp4zmLxcFPLLpz93kNwd1wm53XQ
[:db_condition_placeholder_1] => 
)
in Drupal\Core\Database\Connection->query() (line 569 of \core\lib\Drupal\Core\Database\Connection.php).
Drupal\Core\Database\Connection->query('...', Array, Array)
Drupal\Core\Database\Query\Select->execute()
Drupal\Core\Database\Query\Merge->execute()
Drupal\Core\Session\SessionHandler->write('lFpSVzn8fEmt1B995GB3NpJAWcHR9918iI45OckM2EA', 'batches|a:1:{i:854;b:1;}')
session_write_close()
Drupal\Core\Session\SessionManager->save()
Drupal\Core\Authentication\Provider\Cookie->cleanup(Object)
Drupal\Core\Authentication\AuthenticationManager->cleanup(Object)
Drupal\Core\EventSubscriber\AuthenticationSubscriber->onRespond(Object, 'kernel.response', Object)
call_user_func(Array, Object, 'kernel.response', Object)
Symfony\Component\EventDispatcher\EventDispatcher->doDispatch(Array, 'kernel.response', Object)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch('kernel.response', Object)
Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.response', Object)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\HttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)
drupal_handle_request()
#
PDOException: SQLSTATE[HY000]: General error: failed to instantiate user-supplied statement class in Drupal\Core\Session\SessionHandler->write() (line 201 of \core\lib\Drupal\Core\Session\SessionHandler.php).Drupal\Core\Session\SessionHandler->write('lFpSVzn8fEmt1B995GB3NpJAWcHR9918iI45OckM2EA', 'batches|a:1:{i:854;b:1;}')
session_write_close()
Drupal\Core\Session\SessionManager->save()
Drupal\Core\Authentication\Provider\Cookie->cleanup(Object)
...
...
#
PDOException: SQLSTATE[HY000]: General error: user-supplied statement does not accept constructor arguments in Drupal\Core\Session\SessionHandler->write() (line 201 of \core\lib\Drupal\Core\Session\SessionHandler.php).Drupal\Core\Session\SessionHandler->write('lFpSVzn8fEmt1B995GB3NpJAWcHR9918iI45OckM2EA', 'batches|a:1:{i:854;b:1;}')
session_write_close()
Drupal\Core\Session\SessionManager->save()
Drupal\Core\Authentication\Provider\Cookie->cleanup(Object)
...
...
#
{"status":true,"percentage":"100","message":"","label":"Processed test 1 of 1 - \u003Cem class=\u0022placeholder\u0022\u003EWebTestBase environment\u003C\/em\u003E.\u003Cdiv class=\u0022simpletest-fail\u0022\u003EOverall results: 2 passes, 0 fails, 2 exceptions\u003C\/div\u003E\u003Cdiv class=\u0022item-list\u0022\u003E\u003Cul\u003E\u003Cli\u003E\u003Cdiv class=\u0022simpletest-fail\u0022\u003EWebTestBase environment: 2 passes, 0 fails, 2 exceptions\u003C\/div\u003E\u003C\/li\u003E\u003C\/ul\u003E\u003C\/div\u003E"}

As you can see in this patch, I already tried various things to figure out the cause for that exception, but to no avail.

Awesome idea! :-)

Let's do this. We can look into the problem discovered in #3 in a separate issue (session of UI test runner leaking into all web tests).

@znerol additionally dug out the original issue that introduced this static variable — however, it does not contain any discussion nor an explanation for why the static variable was added.

Even before PHP 5.4, session_status() === PHP_SESSION_ACTIVE is identical to this:

session_id() !== ''

See also http://php.net/manual/en/function.session-status.php#113468

Therefore, it is not clear why that static variable ever existed to begin with. It looks like it was unnecessary all of the time.

Great! — That makes some more sense now.

Definitely fine to simply remove it then. :-)

Adjusting issue title + summary accordingly.

After my debugging investigations in #3, I actually consider this a bug now, since session_write_close() ends a session, but due to the static variable, and because that variable is never reset to FALSE, Drupal still believes that there is an active session.

There is no code in core/HEAD that checks whether a session is active after writing+closing it (typically at the end of a request), but SessionManager::isStarted() definitely returns a wrong status in that case right now.

Sorry, one more issue title adjustment — I think this new one properly describes the hidden bug.

Moved #3 into new #2239969: Session of (UI) test runner leaks into web tests