ErrLookup › Background articles › 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty

'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty

'Could not be found', 'does not exist', 'not found in database', 'not valid', 'not registered' — these errors fire when a library resolves a resource by an identifier you supplied and the lookup returns nothing. You meet them when a delete races your update, a slug or key is typo'd or miscased, the ID actually belongs to another database, user, or environment, or the resource is hidden by permissions or filters rather than truly absent. Across 200 documented records in 20 repositories, this article explains the mechanism, why the same miss surfaces as 400, 404, 500, a typed error code, or a CLI abort, and which fixes hold everywhere.

Distilled from 200 documented records across 20 repositories.

Background

This family lives at the application layer, one step above transport. The call reaches the library's code and the channel works; a lookup then runs — findOne against a table, an equality filter over a fetched list, a map-key compare in a registry, a file-existence check, an OS enumeration of windows and displays — and comes back empty, so the code throws or returns an error naming the resource. No real HTTP request has to fail: LiteLLM's ModelsManagementClient.get() wraps a synthetic requests.exceptions.HTTPError (with an empty Response) around a locally detected miss after a successful list call, and the Electron screen-capture variant surfaces as a failed getUserMedia media request, not an HTTP response at all.

From the caller's side every case shares one shape: you hold a reference you believe is valid — an ID, slug, URI, name, or opaque handle — and the store disagrees. Usually the reference was captured earlier and server state moved on: the row was deleted by a racing request (a second admin removing the same team member, a cascading delete mid-transaction, a double-submit in the UI), the resource was deleted and re-created with a new ID (a re-authorized WebDAV account, a recreated collection), the window or display behind an opaque handle vanished, or the identifier was never re-validated after a restart, a workspace switch, or an environment change.

How the miss surfaces varies more than anything else about the family. Some libraries raise typed errors — LiteLLM's not_found_error with HTTP 404, Appwrite's document_not_found, Rocket.Chat's member-does-not-exist — while others throw plain Errors that the transport layer turns into a generic 500 (Rocket.Chat's integration lookup has no error code to match on). AnythingLLM returns 400 Bad Request for a missing workspace slug on delete, 500 for deleting a missing agent flow, and a bare 404 on its update-pin route, where a completely unknown workspace slug instead dies as a TypeError in the catch handler. CLI tools (occ dav:delete-subscription, siyuan's notebook commands) pre-validate and abort with no side effects. At least one path — an Appwrite function-variables delete — reports its not-found condition under a message about certificate paths, so message text alone cannot always be trusted to name the failure.

The second axis of variation is what 'not found' claims. Often the row is genuinely absent. But Appwrite's GET document runs under the caller's roles and returns the same message whether the document is gone or merely not readable by you — existence is deliberately not leaked — and disabled databases and collections are masked as not-found for session users while API keys and privileged users see the real state. LiteLLM's team bulk-key update deliberately excludes blocked and expired keys, so a team whose keys all expired reports 'No keys found'. Whether missing, forbidden, and filtered-out are distinguished is library-specific; check the record for the exact path you are on.

Common causes

What usually fixes it

Go deeper

Documented occurrences

…and 180 more across the corpus — use search.

Honest provenance: generated on 2026-08-20 from AI-assisted analysis of the linked records. See how records are made.