← All learning

REPAIR GUIDE / WORKING THROUGH A REAL FAILURE

Why your AI app loses data after refresh

Find the source of truth and prove persistence with a restart and concurrent-write test.

OPEN THESE FILES

store.mjs · test.mjs

Reproduce the loss precisely.

Create two fictional enquiries and note their IDs. Refresh the browser. If they disappear, inspect whether the app only kept them in a JavaScript array. If they survive refresh but disappear when Node restarts, the server may still be storing them only in memory.

Write down where the authoritative records live. Browser memory, browser storage, server memory, a server file, and a managed database have different lifetimes. Do not choose a repair until you know which boundary lost the data.

Inspect the reference.

In the source kit, store.add writes the complete update before the route returns a receipt. createStore reads existing records on startup and refuses unreadable data. It does not quietly replace a corrupt file with an empty array.

npm test

Read the test named “storage survives restart, serializes concurrent writes, and deduplicates retries.” It creates ten records at the same time, reopens the file, and checks the count. This catches updates that overwrite each other after reading the same old state.

Check the host as well as the code.

A working local file does not establish durable cloud storage. The teaching app requires one writer and a persistent disk. For a serverless or multi-instance deployment, move the source of truth to a transactional database. Back up the original records before changing the storage path.

Use the persistence lesson for the complete flow and the deployment lesson for the restart check.

Prove it before moving on.

  • The original IDs survive browser and server restarts.
  • Concurrent submissions are all present.
  • A bad data file causes an explicit error.

Use these as checks in your own app. This page does not store course progress.