A form can show a success message and still forget everything after a reload. Before asking an agent to 'fix saving,' identify where the data is meant to live. A single-user practice board can use browser storage; a shared customer app usually needs an authorized backend and database. The right fix depends on that product decision, not on the button's appearance.
Reproduce the exact loss before editing
Use a disposable test record, note the page URL, signed-in account, browser, and steps, then save and reload once. Check whether the value disappears immediately, after a full refresh, after closing the tab, or only in another browser or device. These are different failures. Also note whether a success message appeared and whether the item returns after signing in again. In Canopy, run the app from the intended checkout and inspect that same local URL; another server or branch can make a previous fix seem absent.
- Use a unique test label, not customer data, so you can tell which save you are viewing.
- Record expected persistence: this tab, this browser, this account, or all signed-in devices.
- Do not clear storage or reset the database during initial diagnosis.
Find where Save actually writes
Inspect the Save handler and the browser Network panel. If no write request occurs, the page may be changing only in-memory component state or browser storage. React describes component state as UI memory tied to the rendered tree, not a durable database. Chrome's Application panel shows Local Storage for the page origin; MDN says localStorage persists across browser sessions for that origin, while sessionStorage ends with the page session. A successful network request is also not enough by itself: inspect its status and the backend record or follow-up read in the approved test environment. Avoid pasting a request body containing private data into an agent transcript.
| Observed behavior | Place to inspect | What it does not prove |
|---|---|---|
| Value disappears on refresh | Component state, Save handler, request log | The database is broken; there may be no write |
| Survives refresh in one browser | Local Storage, IndexedDB, or backend read | Another user or device can see it |
| Survives browser close on one device | Origin-scoped browser storage or backend | It is backed up or account-owned |
| Appears on another signed-in device | Backend record, auth rule, fresh read | All users have correct access controls |
Choose the persistence the feature requires
For the included first-agent practice board, localStorage is intentional: the README says tasks stay in this browser on this device, and there is no login or backend. For customer profiles or team records, define who owns the data, which accounts can read or change it, how errors appear, and which backend stores it. Do not replace a broken backend write with localStorage just to make the refresh test pass; that can hide lost synchronization and access rules. Conversely, do not add a database to a small offline exercise that only promises same-browser persistence. If a backend is needed, first confirm its development target so the agent does not test against production data.
- Write the expected persistence scope into the task brief.
- Name the authorized test environment and safe record type.
- Get a qualified review for account, authorization, migration, or customer-data changes.
Ask the agent for a checkable fix
Give the agent the reproduction and ask it to trace the Save handler, storage call or API request, reload path, and existing tests before editing. The acceptance check should cover one successful save, one failed save, refresh, and the appropriate second-context test: a new tab for origin-scoped browser storage or another signed-in device for account-backed data. Ask it to report the exact changed files, run command, request outcome, and backend target without exposing credentials. In Canopy Preview, repeat the sequence yourself and compare the final diff with the product's agreed storage rule.
- A visible success message should follow a confirmed save, not merely a click.
- A failed write should leave the input available and explain what happened.
- Test a second account when authorization is part of the feature, not only a second tab.
Check the final PR for a demo-only shortcut
Read the final diff for hardcoded sample values, a Save button that only changes local UI state, an added browser-storage fallback that hides backend errors, or a test weakened to assert only a toast. If the implementation changes a database schema, API, or auth rule, use the corresponding review workflow and verify the latest commit and test environment. A passing build and a screenshot of the saved state cannot show what happens after refresh or for another authorized user. Accept the task only after the observed behavior matches the written persistence promise.
- Verify the same branch, service, and URL used by the agent.
- Repeat the failure path after the last code change.
- Record the exact persistence scope in the PR or product documentation.
Copyable resources
Data disappears after refresh: agent task
Replace the storage promise with what this product actually needs.
Page, URL, browser, account, checkout, and branch: [ ]
Test record (disposable): [ ]
Steps: create or edit [ ]; click Save; observe [ ]; refresh; observe [ ].
Expected persistence: same tab / same browser / same account across devices [choose one].
Before editing: trace Save handler, browser storage, network write, backend target, reload read, and existing tests. Cite files and unknowns.
Approved test environment and data: [ ]; do not use production data.
Acceptance: successful save; failed save with recoverable input; refresh; second tab or second device/account as appropriate.
Delivery: running URL, exact request or storage evidence, tests and results, changed files, final diff, remaining risks.Frequently asked questions
Is localStorage the same as a database for my users?
No. It is browser storage scoped to an origin and the user's browser context. It can suit a local single-user exercise, but it does not by itself synchronize an account across devices or provide a shared backend.
Why did the success message appear if nothing saved?
The UI may show success after a local state change or before checking the server result. Trace the handler and request, then test the value after a fresh read or reload.
Does a page surviving refresh prove the feature is ready?
No. Check the promised persistence scope, failure behavior, access rules, and the final code diff. Browser storage can survive refresh without making the record available to the correct account on another device.