Stale Data Shown After Update
After a record is successfully updated, the application continues to display the old value. This happens because the frontend does not re-fetch data after a successful write, a server-side cache is not invalidated on update, or a read replica with replication lag returns the pre-update value immediately after the write.
MediumBeginnerManual testingAPI testingExploratory testing
// UNDERSTAND
// Symptoms
- After saving a change, the old value reappears when the page is refreshed
- The edit form shows a success message, but navigating back to the record displays the pre-edit value
- Two users viewing the same record simultaneously see different values after one of them saves an update
- A GET request immediately after a successful PATCH returns the old field value
// Root Cause
- The frontend fetches data once on page load and does not re-fetch or invalidate its local state after a successful PUT or PATCH response
- A server-side cache (in-memory, Redis, or CDN) holds the old value and is not purged when the record is written
- The application uses optimistic UI updates that temporarily display the new value, but a subsequent cache hit on the next navigation restores the old one
- A read replica with replication lag returns the old value when queried immediately after a write to the primary database
// Where It Appears
- User profile and account settings pages
- Content management systems where articles or posts can be edited
- Dashboard and reporting pages that cache query results
- Distributed systems with eventually consistent read replicas
- Any read-heavy application that caches resource GET responses
// REPRODUCE & TEST
// How to Reproduce
- 01Navigate to a record with an editable field (e.g. the user profile settings page with a display name field)
- 02Note the current value of the field (e.g. display name: 'Alice')
- 03Edit the field to a new value (e.g. 'Alice Smith') and save the changes
- 04Confirm the success message or 200 response appears
- 05Navigate away from the page (e.g. go to the homepage)
- 06Navigate back to the same settings page and observe the displayed value
// Test Data Needed
- A user account with at least one editable field
- Optionally: a second browser session to observe the multi-user staleness variant
// Manual Testing Ideas
- Edit a record and immediately refresh the page to check whether the new value persists
- Edit a record in one tab; open the same record in a second tab and compare the displayed values
- Edit a record, log out, log back in, and check whether the updated value is shown
- Inspect the Network tab in DevTools: does the page send a fresh GET after a successful PATCH, or rely on the cached response?
- Check response headers (Cache-Control, ETag, Expires) on the GET request to identify caching rules
- Disable the browser cache in DevTools (Network > Disable cache) and repeat — if the stale value disappears, the bug is client-side caching; if it persists, the bug is server-side
// API Testing Ideas
- Send GET /api/users/123 and record the current value of the name field (e.g. 'Alice')
- Send PATCH /api/users/123 with {"name": "Alice Smith"}; assert the response is 200 or 204 confirming the update
- Immediately send GET /api/users/123 again
- Assert the name field in the response is 'Alice Smith' — not the old value 'Alice'
- Wait 3 seconds and send GET /api/users/123 a third time
- Assert the updated value persists — a reversion indicates a server-side cache is re-serving stale data
// Automation Idea
Automate a PATCH request to update a record field, then send GET requests at three intervals: immediately, after 1 second, and after 5 seconds. Assert the updated value is returned at all three points. Any interval that returns the old value identifies when the cache expiry or replication lag causes staleness.
// Expected Result
Immediately after a successful update, any subsequent request for the same record returns the updated value.
// Actual Result (Example)
After a successful PATCH /api/users/123 updating the name to 'Alice Smith', a GET /api/users/123 returns { "name": "Alice" } — the pre-update value.
// REPORT IT
Example Bug Report
- Title
- User profile display name reverts to old value after editing and refreshing the page
- Severity
- Medium
- Environment
- Staging environment Chrome 124 Standard user account
- Steps to Reproduce
- 01Log in and navigate to the user profile settings page
- 02Note the current display name value (e.g. 'Alice')
- 03Update the display name to 'Alice Smith' and click Save
- 04Confirm the 'Saved successfully' message appears
- 05Navigate to the homepage, then navigate back to the settings page
- 06Observe the display name field value
- Expected Result
- The display name shows 'Alice Smith' after navigating back.
- Actual Result
- The display name shows 'Alice' — the value before the edit — after navigating back to the settings page.
- Impact
- Users cannot trust that their saved changes have taken effect, leading to repeated unsuccessful save attempts, frustration, and loss of confidence in the application.