ErrLookup › Background articles › "User not found", "Invalid user", and "does not exist": what missing-user lookup errors mean across Rocket.Chat, LiteLLM, Phabricator, rustfs, and pnpm

"User not found", "Invalid user", and "does not exist": what missing-user lookup errors mean across Rocket.Chat, LiteLLM, Phabricator, rustfs, and pnpm

"User not found" and its siblings ("Invalid user", error-invalid-user, NoSuchUser, "No such user exists") fire when code resolves a username, userId, or access key against a user store and the lookup comes back empty. Developers hit this family across Rocket.Chat methods and REST endpoints, LiteLLM's proxy user routes, Phabricator CLI workflows, rustfs IAM operations, and pnpm registry commands — usually because of a typo'd or renamed identifier, a deleted account, a stale session token, or a value (display name, email, or ID) sent where a different identifier type was expected.

Distilled from 78 documented records across 10 repositories.

Background

This family sits at the identity-resolution layer: after authentication succeeds and before the real operation runs, nearly every library performs a lookup — Users.findOneByUsername, findOneById, prisma get_data, PhabricatorPeopleQuery, an IAM store read — and throws when the result is null. The error is therefore a precondition failure, not a crash: no side effects have occurred (Rocket.Chat's deleteUser, for example, checks the target before any protection logic or deletion). From the caller's side it surfaces as a 400/404 HTTP response, a Meteor.Error like error-invalid-user, a CLI PhutilArgumentUsageException, or a 404-class IAM error, almost always naming the identifier that failed to resolve.

The semantics vary by which identifier was looked up. Username-based lookups (Rocket.Chat's REST params, integration post-as users, roles.removeUserFromRole; Phabricator's --from; pnpm stars) are typically exact and often case-sensitive, so display names, emails, wrong casing, or trailing whitespace all miss. ID-based lookups (Rocket.Chat's findOneById paths, LiteLLM's user_id fetches) fail on typos, truncation, URL-encoding differences ('+' decoded to a space in LiteLLM), or accounts deleted after the ID was captured. A distinct sub-group is the stale-session case: the acting user's own record vanished while their token stayed valid, which several Rocket.Chat methods (getMentionedMessages, setReaction, banUser) flag as an integrity signal meaning "re-authenticate," not "retry."

Libraries disagree on how much the error tells you. LiteLLM's /v2/user/info deliberately returns the same 404 whether the user is missing or merely forbidden, to avoid leaking which IDs exist; rustfs's NoSuchUser embeds the access key in the message; Rocket.Chat mostly interpolates nothing and relies on separate error codes (error-invalid-user vs error-invalid-desired-user vs error-user-param-not-provided) to distinguish value-supplied-but-unmatched from param-omitted. Some throws are misleading: Rocket.Chat's unarchiveRoom error details name 'archiveRoom' (a copy-paste artifact), and 'User is not in this room' from removeUserFromRoom actually means the user does not exist in the workspace at all, not that membership is missing.

Behavior on failure also varies: Rocket.Chat's addUsersToRoom runs inside Promise.all, so one unknown username rejects the entire invitation batch, while its delete/update flows treat the miss as a clean no-op state. pnpm adds a registry wrinkle — a 404 on user stars can mean the registry never implemented the /-/user/<name>/stars endpoints, making every username "not found" regardless of existence.

Common causes

What usually fixes it

Go deeper

Documented occurrences

…and 58 more across the corpus — use search.

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