RocketChat/Rocket.Chat · error · Error

Invalid user status type

Error message

Invalid user status type

What it means

Thrown by createFromCustom on the UserStatuses store when the provided customUserStatus.statusType is not a valid value in the UserStatus enum. isValidType checks whether the string is among Object.values(UserStatus). The UserStatus enum contains values like 'online', 'away', 'busy', 'offline' (and possibly others). This validates that a custom status name maps to a recognised status type.

Source

Thrown at apps/meteor/client/lib/userStatuses.ts:40

				id: status,
				name: status,
				statusType: status,
				localizeName: true,
			},
		]),
	);

	public delete(id: string): void {
		this.store.delete(id);
	}

	public put(customUserStatus: UserStatusDescriptor): void {
		this.store.set(customUserStatus.id, customUserStatus);
	}

	public createFromCustom(customUserStatus: Omit<ICustomUserStatus, '_updatedAt'>): UserStatusDescriptor {
		if (!this.isValidType(customUserStatus.statusType)) {
			throw new Error('Invalid user status type');
		}

		return {
			name: customUserStatus.name,
			id: customUserStatus._id,
			statusType: customUserStatus.statusType as UserStatus,
			localizeName: false,
		};
	}

	public isValidType(type: string): type is UserStatus {
		return (Object.values(UserStatus) as string[]).includes(type);
	}

	public *[Symbol.iterator]() {
		for (const value of this.store.values()) {
			if (this.invisibleAllowed || value.statusType !== UserStatus.OFFLINE) {
				yield value;

View on GitHub (pinned to f9d3ec372b)

Solutions

  1. Validate the statusType against Object.values(UserStatus) before calling createFromCustom.
  2. Ensure client and server are on compatible versions that share the same UserStatus enum values.
  3. Map external status types to known UserStatus values before creating a custom status.
  4. Catch the error and fall back to a default status type (e.g., 'online').

Example fix

// before
const status = userStatuses.createFromCustom({ _id, name, statusType: inputType });
// after
if (!userStatuses.isValidType(inputType)) {
  inputType = UserStatus.ONLINE; // fallback
}
const status = userStatuses.createFromCustom({ _id, name, statusType: inputType });
Defensive patterns

Strategy: type-guard

Validate before calling

if (!userStatuses.isValidType(statusType)) {
  statusType = UserStatus.ONLINE; // fallback to default
}
const status = userStatuses.createFromCustom({ _id, name, statusType });

Type guard

userStatuses.isValidType(type: string): type is UserStatus  // already provided by the library
// usage:
if (userStatuses.isValidType(inputType)) {
  // inputType is narrowed to UserStatus
  userStatuses.createFromCustom({ ..., statusType: inputType });
}

Try / catch

try {
  const status = userStatuses.createFromCustom({ _id, name, statusType });
} catch (e) {
  if (e instanceof Error && e.message === 'Invalid user status type') {
    // fall back to a valid type
    statusType = UserStatus.ONLINE;
  }
}

Prevention

When it happens

Trigger: A custom user status is created with a statusType string that is not in the UserStatus enum (e.g., 'invisible', 'do-not-disturb', or a typo like 'busyy'). Data from an external source or API response includes a status type the client does not recognise. Version mismatch: the server sends a status type added in a newer version the client doesn't know.

Common situations: Server-side custom status plugin adds new status types the client enum doesn't include. Imported data from a third-party integration with different status type names. Client-server version skew after a server upgrade. Hardcoded status type string with a typo in custom integration code.

Related errors


AI-assisted analysis of RocketChat/Rocket.Chat@f9d3ec372b (2026-08-12). Data as JSON: /api/errors/d1c9e1823362fa3b. Report an issue: GitHub.