Saved data that disappears

1. Record one save.

   In Chrome, right-click the app, choose Inspect and open Network. Clear the request list, then save your disposable record once. Look for the request triggered by that action. Select it and read its status and Response, including any returned record id.

2. Read the item again.

   Reload the page with Network still open. Select the request that loads the list and inspect its Response. Search for the distinctive name or returned id. Note whether the item is absent from the response or only absent from the screen.

3. Check the intended storage.

   In your database dashboard, open the project named by the app’s request URL and find the test record. Compare its owner and id with the signed-in account. Do not edit the record during this observation.

4. Compare a second browser.

   Sign into the same test account in an incognito window and look for the item. If it exists only in the first browser, inspect Application, Local Storage for that site to check whether the app kept the item there instead of sending it to shared storage.

WORKSThe saved test record is returned by a fresh read for its owner.

BROKENThe write fails, reaches the wrong store or cannot be read back as intended.

FAKEDThe app announces a save without performing the persistence it promises.

Ranked in the order to investigate, not by claimed frequency.

1. The save never reached shared storage.

   Connect the save action to the intended persistence operation. Wait for its result before showing success, and show a useful failure if the write fails. A temporary screen update is not evidence of a completed save.

2. The item exists but the next read excludes it.

   Compare the read’s owner filter and access policy with the saved row. Correct the mismatch without removing ownership protection. Recheck with the owner and with a different account.

3. Preview and live use different stores.

   Point each environment at its intended project and migrate needed data deliberately. Do not copy development secrets into browser code to make the production list appear.

• Local storage is specific to a browser origin. Changing from a preview address to a custom domain does not transfer those locally stored items.
• A failed list refresh can leave an older view on screen. Check the actual read response before concluding that a successful write was lost.

When to stop and hand it over

Stop if important records are missing from the database itself or if you cannot tell which project owns them. Preserve the record ids and request times. Ask for a storage and backup review before importing, deleting or retrying large batches.