## Problem/Motivation `idle_reauthenticate_user_login()` in `idle_reauthenticate.module:29` writes to the private temp store: ```php \Drupal::service('tempstore.private') ->get('idle_reauthenticate') ->set(\Drupal::service('session_manager')->getId() . ':state', PingBack::STATE_UNBLOCKED); ``` There are two problems with this one line. ### 1. The write is unguarded against TempStoreException `PrivateTempStore::set()` throws `TempStoreException` when the lock backend cannot be acquired. #3599008 fixed the five call sites in `PingBack`; this sixth one was deliberately left out of that scope. Here the consequence is worse than the heartbeat failure #3599008 dealt with. The exception would be thrown from inside `user_login_finalize()`, so a user who submitted entirely correct credentials during lock contention gets a WSOD instead of a login. The session has already been migrated and `uid` already set by the time the hook runs, so the login is left half-completed. ### 2. The key it writes can never be read Observed while developing the test coverage for #3599008: this hook writes the temp store key `2::state` — that is, owner `2` followed by an **empty** session ID. `PingBack::getKey()` builds its keys from the same `session_manager->getId()` but gets a real session ID, so the two never agree. The entry the login hook writes is orphaned on every single login and simply waits out its expiry. Probable mechanism, worth confirming as part of the fix: `user_login_finalize()` calls `$session->migrate()` immediately before invoking `hook_user_login()`, and `SessionManager::regenerate()` returns early without regenerating when `session_status() !== PHP_SESSION_ACTIVE` — the normal case for an anonymous visitor submitting the login form. The ID would then only be assigned once the session is actually started and written, which is after the hook has run. The practical effect is that the intended "this session starts out unblocked" marker is never actually seen by anything. The behavior is nevertheless correct today, because `PingBack` falls back to `STATE_UNKNOWN` when the entry is missing and treats anything other than `STATE_BLOCKED` as unblocked — but that is correct by accident rather than by design, and every login leaves a stray entry behind. ## Steps to reproduce 1. Install the module and log in as any user. 2. Inspect the temp store: `SELECT name FROM key_value_expire WHERE collection = 'tempstore.private.idle_reauthenticate';` 3. Observe an entry named `<uid>::state`, with an empty session ID segment, that no subsequent request ever reads. ## Proposed resolution 1. Decide whether the hook needs to write at all. Since `PingBack` already treats a missing entry as not blocked, removing the write may be the simplest correct fix. 2. If the write is kept, obtain the session ID at a point where it has actually been assigned, and handle `TempStoreException` so that lock contention can never break a login. The `storeSet()` helper added to `PingBack` in #3599008 shows the intended error policy. 3. Either way, add test coverage. The functional test harness added in #3599008 (`tests/modules/idle_reauthenticate_test`, whose lock backend can be told to refuse every lock on demand) can be reused as is. ## Remaining tasks - [ ] Confirm the empty session ID and its mechanism with a test. - [ ] Decide whether to remove the write or fix and guard it. - [ ] Add test coverage for a login while the lock is unavailable. - [ ] Run phpcs, phpstan, cspell and phpunit. ## User interface changes None. ## API changes None. ## Data model changes None. Related: #3599008 --- AI-Generated: Yes (Used OpenCode to analyze the module while working on #3599008, where this was found, and to draft this issue summary.)