Data stops getting stored to session

[joelanman]

Description of the issue

We're getting a few reports that data stops getting stored to session sometimes. Clearing .tmp/sessions seems to fix Other reports suggest this happens in Chrome and not other browsers

Steps to reproduce the issue

• Make a prototype that records and displays data
• Go through the prototype, it sometimes stops storing data

Actual vs expected behaviour

• session data should be stored and usable unless cleared

Environment (where applicable)

• Operating system:
• Browser:
• Browser version:
• GOV.UK Prototype Kit version:

[enoranidi]

I have added a video to show what is happening for me at the moment when I use the latest version of Chrome and the GOV.UK Prototype Kit: https://www.loom.com/share/7ac82f624a3141aba433d9d309bd352d?sid=e8c845f2-0a70-400e-92f3-f93401d7d81d

[enoranidi]

Operating system: macOS Sonoma Browser: Chrome Browser version: 121.0.6167.184 (Official Build) (arm64) GOV.UK Prototype Kit version: v13.16.0

[StuBamforthDWP]

Loom video showing my issue with data not being passes through pages. The applicant name and organisation name are inserted into subsequent questions to add context, the applicant name isn't being passed through. Also the details captured in the questions are not being displayed on the Check your answers page.

https://www.loom.com/share/6b33464f6bc346c38b9dfea4835e7779?sid=bf532f85-42e8-41ec-a259-2477d4352b08

[StuBamforthDWP]

Operating system: macOS Catalina 10.15.7 Browser: Chrome Browser version: 121.0.6167.184 (Official Build) (x86_64) GOV.UK Prototype Kit version: v13.16.0

[StuBamforthDWP]

Clearing .tmp/sessions via the Terminal fixed the issue for me.

Entered:

rm -rf .tmp/sessions

in the VS Code terminal.

Then restarted the app and it's working again.

[HarryMtds]

I am having the same issue that everyone else is. It affects prototypes running locally and in Heroku.

I've not been able to reproduce the error reliably. It happens randomly when moving from one page, through a route to another page. It forgets everything stored in session and the session object is no longer able to be read from or written too.

Given that clearing all the JSON files in .tmp/sessions fixes the issue- I think that something in there is the cause of the issue. I would go through these and check but given that a new JSON session file is created on every page load, this would take a prohibitive amount of time.

Operating system: MacOS 14.3.1 (23D60) Browser: Chrome Browser version: 121.0.6167.184 GOV.UK Prototype Kit version: 13.16.0 Node version: 20.10.0

[joelanman]

@HarryMtds thanks, does it happen in other browsers?

[HarryMtds]

Can't seem to replicate it in Safari. I have noticed an interesting difference in behaviour between Chrome and Safari.

Chrome:

1. Delete all files in .tmp/sessions
2. Open localhost:3000
3. Two JSON files are created in .tmp/sessions The difference between these files is the cookies.expires value

Safari:

1. Delete all files in .tmp/sessions
2. Open localhost:3000
3. One JSON file created in .tmp/sessions

Edit:

On further inspection, chrome generates a new session file on every page load, whereas Safari does not

[joelanman]

@HarryMtds super helpful thanks!

[36degrees]

I've been trying to get to the bottom of what's going on here… a few observations so far…

• 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 which results in an extra session being created (and never reused) every time the page is loaded. I believe this explains the difference in behaviour between Chrome and Safari described in https://github.com/alphagov/govuk-prototype-kit/issues/2393#issuecomment-1956633304. I don't think this is the root cause of the bug, but I think it might be making it more likely, be increasing the number of sessions that need to be stored.
• We're setting resave: false. The guidance for resave says 'the best way to know is to check with your store if it implements the touch method. If it does, then you can safely set resave: false. If it does not implement the touch method and your store sets an expiration date on stored sessions, then you likely need resave: true.' As far as I can tell, our session store does not implement touch. But I still don't really understand what resave does and whether this is relevant or not.
• I'm reasonably sure I've observed expiry dates in the session files being updated with older dates, i.e. the time to their expiry being shortened, but I've not yet worked out why this is happening (or, indeed, if I was imagining it…)

[joelanman]

the timing of the issue seems to point to the manifest being a possible cause - we could try asking people who see this issue to try something like this in their app/views/layouts/main.html:

{% block headIcons %}{% endblock %}