We store session data in the filesystem using our own session `FileStore` class. Each session is stored as a separate JSON file inside `.tmp/sessions` with an expiry date and the data for session.
As part of the `set` method for the FileStore class, we have some logic which tries to clean up expired sessions from the filesystem.
This loops through all of the files in the session store directory and checks each one in turn to see if the expiry date in the JSON is in the past. If it is, it calls `this.destroy` passing the `storedSessionId`. This happens asynchronously – we map over the files in the directory to create an array of promises, each of which awaits a call to the filesystem to read the JSON.
Unfortunately, `storedSessionId` is scoped to the outer `set` method and is therefore affected by the other promises that are running concurrently.
Because of this, when there are expired sessions in the session store, it’s possible for non-expired sessions to be destroyed instead, depending on the value of `storedSessionId` at the time destroy is called.
Furthermore, because this leaves the expired session in place, further attempts to set data are likely to continue cleaning up the non-expired sessions.
You can observe this (and verify that this fixes the issue) by:
1. Adding logging just before the call to this.destroy on line 23:
```
console.log(`Destroying expired session ${storedSessionId}`)
```
2. Clearing all session data by deleting `.tmp/session`
3. Generating multiple non-expired sessions by refreshing the Prototype Kit multiple times [^1]
4. Manually updating the expiry date in the JSON for one of the sessions to be in the past [^2]
5. Refreshing the kit and observing that a session with a different ID is destroyed
Fix this by correctly scoping the `storedSessionId` variable to the asynchronous function, preventing it being altered by other promises resolving at the same time.
Due to the limited support we are currently able to provide for the kit, I have made the smallest possible change I believe fixes the bug and not done any further refactoring.
Also, whilst I believe it would be beneficial to have tests that cover this code (including this specific bug) I have not done this as it’s non-trivial and involves mocking the file system.
Closes #2393.
[1]: This works because the request for the new manifest added in GOV.UK Frontend v5.0 (served at `/plugin-assets/govuk-frontend/dist/govuk/assets/manifest.json` in the kit) is made without credentials (see the note on https://web.dev/articles/add-manifest) which results in an extra session being created (and never reused) every time the page is loaded. I think this also might have made this bug more likely to occur because of the sheer number of session files that get created.
[2]: In case it’s useful for testing, this jq command shows the expiry date for all current sessions:
```
jq -r -n 'inputs | "\(input_filename) \(.cookie.expires)"' .tmp/sessions/*.json | sort | head
```
Co-authored-by: Colin Rotherham <[email protected]>