[NM-66] Hot fix for state being rewritten on a project

[r-ash]

Description

See ticket for more details, this stops mutations from updating local storage between when a project load replaces local storage with the new project to be loaded and when the browser refreshes.

You should be able to recreate the bug fairly easily on prod (and locally) by opening a project onto review input step with a large country e.g. Kenya. Then go back to projects and create a new project and fit the model. Then switch between the projects a few times in succession. Wait for the Kenya project to initiate a fetch for input plot data before swapping out. You should see (it might take a couple of attempts) that the completed projects later steps will become invalid.

This is deployed on preview at the moment and I cannot recreate it there.

Type of version change

Patches

Checklist

• I have incremented version number, or version needs no increment
• The build passed successfully, or failed because of ADR tests

[r-ash]

I was also occasionally getting errors from shapeData.data.features being null in the call to getDataWithAreaLevel. So making this check cover that case too.

[M-Kusumgar]

this is definitely the correct place to target this bug, i managed to recreate it however theres a bigger issue with all this save state into local storage stuff, local storage is shared between tabs so your goal of making saving state atomic means that you must block saving state at any point theres a change, not just when a project is loading, but also when it decided to save state every 2 seconds for example, so one thing i was able to do after a couple attempts is:

1. create a DRC project, stop at review inputs
2. create a MWI project, go to output plots
3. load DRC and MWI on two separate tabs
4. wait for state saving of MWI (2 sec interval thing)
5. reload DRC (this is a bit flaky) and you can get into a state that DRC is actually on the output plots step because somewhere we are saving a partial state with just the stepper state i am guessing

like shown here, note the zomba city error (city in malawi) and DRC area filter

if you want to further avoid these issues, i would save full states in local storage only and i would also potentially change the structure of the saved states in localstorage to be an object with keys equal to sessionId and value their local storage, which means that you can actually have things open on multiple tabs without them interacting with each other,

note: you could even skip saving only full states with this because saving partial states makes sense if you have the correct sessionId but honestly i always prefer to wipe and reconstruct because it costs almost no extra time and is cleaner

but yh since local storage is shared between tabs, its tricky with stuff like this!

ps: with two tabs you can also create 2 projects with the same name :)

[r-ash]

Thanks @M-Kusumgar chatted about this

Follow ups which I will make a ticket for

1. Backend should prevent creating a project with the same name
2. We will update local storage key to be specific to the tab which is open. We should add a limit to the number of these which we keep in local storage (20?) and clean up the oldest entry. Remove the metadata from local storage, this is always refetched
3. Down the line, rethink what we save in local storage. We could just save an ID for a session and have the backend manage returning state to us.

[notion-workspace]

Fix issue with state being overwritten on a project