A delete that does not delete

1. Watch the delete action.

   Open Chrome’s Inspect menu, select Network and clear the request list. Delete the throwaway item once. Select the new request associated with that item and read the method, URL, status and Response. Note any reported error or affected record id.

2. Check what the next read returns.

   Reload the list with Network open. Inspect the list request’s Response and look for the original id. If it is returned, the app can still read that record; the disappearing row alone did not prove deletion.

3. Look at the stored record.

   Open the correct database project and locate the original id. Read whether the row is still present or has a field marking it deleted. Do not manually remove it yet, since that would erase the evidence needed to explain the failed button.

4. Compare ownership and policy.

   Compare the test account with the record’s owner. If the app uses Supabase, inspect the table’s DELETE policy and the SELECT policy that makes the row visible. Check the owner condition instead of disabling row level security.

WORKSA fresh read no longer returns the disposable item in the promised list.

BROKENThe original item returns after the app claims deletion.

FAKEDThe button only hides the item while claiming a persistent delete.

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

1. The interface hides the row without completing a delete.

   Wait for the delete operation and handle its error before presenting success. If the request fails, keep the item visible or restore it with a clear failure message.

2. The request targets no permitted matching row.

   Correct the record id, owner filter or operation-specific access policy. Check that the intended test row is visible and deletable by its owner while another user cannot delete it.

3. The app uses soft deletion but reads all rows.

   If the product intentionally marks items as deleted, make list reads honor that field. State whether deletion means hiding a record or permanently removing it, then test that promised behavior.

• A successful HTTP status can accompany an operation that matched no rows. Read the result and perform the fresh read before stamping the journey as passed.
• A cached list may show a removed item. Compare the database record and the fresh response to avoid changing a working delete because of an old screen.

When to stop and hand it over

Hand it over if ownership rules are unclear, related records make the deletion fail, or the product needs an irreversible purge. Supply the disposable id and redacted request result. Keep real customer data out of the experiment.