# Find out whether a missing row is filtered, stale or unavailable

Table support should reconstruct the query and record state before treating a display problem as missing data.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Capture the view's context

Ask for the page URL, active filters, sort order and relevant record reference. Avoid requesting a full export of customer data when a synthetic reproduction or identifier is sufficient.

Check whether the user is on a later page and whether a filter excludes the record. A status change can legitimately remove a job from an Overdue view without deleting it.

Compare the server's authorised result with the rendered list. This separates query and permission behaviour from a frontend rendering problem.

## Reproduce the sequence that changed the list

Ask what happened immediately before the row disappeared: sorting, searching, returning from detail or changing screen size. Static screenshots may not reveal a stale request that overwrote newer results.

For a synthetic example, apply filter A and then filter B while delaying A's response. If A's rows appear beneath B's controls, engineering has a request-ordering defect to fix.

If the issue concerns selection, inspect record IDs rather than visible positions. A selected third row may refer to a different job after sorting when the implementation incorrectly uses indexes.

## Provide a scoped recovery

Use the supported reset-filter or direct-record path when appropriate. Explain which view state will change before asking the person to reset it.

Before repeating a bulk action, verify its existing outcome and selected identities. A missing success message is not sufficient reason to apply the operation again.

If mobile actions are clipped, provide an approved alternative path while recording the layout defect. Do not close the issue merely because the same task works on a larger monitor.

## Verify and document the cause

Capture a sanitised fixture with the relevant long value, filter sequence or row state. Test the fix with the page shell and overflow containers that produced the problem.

Confirm that browser Back and refresh now restore the intended query state. These paths are frequent sources of reports that a table randomly resets.

Record whether the issue affected visibility, selection or an actual business action. That distinction determines whether data correction is needed in addition to the interface repair.

## Sources

- [W3C WAI: tables tutorial](https://www.w3.org/WAI/tutorials/tables/)