Failed to delete ${mutation.name} (or server-provided messag

Error message

Failed to delete ${mutation.name} (or server-provided message via parseResponseError)

What it means

Thrown in the ElectricSQL collection onDelete mutation handler when the DELETE request to `${mutation.url}/{key}` returns a non-ok HTTP status. It surfaces the server-provided error message via parseResponseError or the fallback 'Failed to delete <name>'. The optimistic local removal cannot be confirmed with a server txid.

Source

Thrown at packages/web-core/src/shared/lib/electric/collections.ts:744

    onDelete: async ({
      transaction,
    }: MutationFnParams): Promise<{ txid: number[] } | void> => {
      const txids = await Promise.all(
        transaction.mutations.map(async (mutationItem) => {
          const response = await makeRequest(
            `${mutation.url}/${mutationItem.key}`,
            {
              method: 'DELETE',
            }
          );

          if (!response.ok) {
            const message = await parseResponseError(
              response,
              `Failed to delete ${mutation.name}`
            );
            throw new Error(message);
          }

          const result = (await response.json()) as { txid: number };
          return result.txid;
        })
      );

      maybeRefreshFallbackAfterMutation(sourceKey);

      if (isSourceFallbackLocked(sourceKey)) {
        return;
      }

      return { txid: txids };
    },
  };
}

View on GitHub (pinned to 4deb7eca8f)

Solutions

Inspect the actual status code in the network tab; the thrown message may carry the server's explanation (e.g. constraint violation).
If 404, the record is already gone — refresh the collection so local state converges and the pending mutation can be dropped.
If 401/403, re-authenticate and retry the delete.
If 409 (referenced by other records), delete or reassign the dependent records first, then retry.

Example fix

// before
await collection.delete(row);
// after
try {
  await collection.delete(row);
} catch (e) {
  if (String(e.message).includes('404')) {
    await collection.refetch(); // already deleted elsewhere
  } else {
    throw e;
  }
}

Defensive patterns

Strategy: try-catch

Validate before calling

const res = await fetch(`${mutation.url}/${row.id}`, { method: 'HEAD' });
if (res.status === 404) await collection.refetch(); // already gone

Try / catch

try {
  await collection.delete(row);
} catch (e) {
  if (e instanceof Error && e.message.startsWith('Failed to delete')) {
    console.warn('Delete failed:', e.message);
    await collection.refetch(); // converge local state
  } else throw e;
}

Prevention

Handle concurrent deletion by refetching instead of retrying the DELETE
Check backend referential constraints before deleting parent entities
Re-authenticate on 401 before surfacing the failure to users
Log the DELETE status code; the fallback message alone hides the cause

When it happens

Trigger: Any non-2xx response from DELETE: 401/403 auth failure, 404 if the record was already deleted, 409 on foreign-key/referential constraints, 5xx backend error.

Common situations: Deleting an item concurrently removed in another tab or session; deleting a parent entity the backend refuses to cascade; stale session token after idle timeout.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

AI-assisted analysis of BloopAI/vibe-kanban@4deb7eca8f (2026-08-29). Data as JSON: /api/errors/cd3236c45af52075. Report an issue: GitHub.