RocketChat/Rocket.Chat · error · Meteor.Error

error-type-param-not-supported

error-type-param-not-supported

Error message

The "type" parameter must be either "UPDATED" or "DELETED"

What it means

messages/get validates the optional type parameter, which selects which cursor history to page (live updates vs trash): it must be exactly 'UPDATED' or 'DELETED'. Anything else — including lowercase or mixed-case variants — throws Meteor.Error 'error-type-param-not-supported' before any data is fetched.

Source

Thrown at apps/meteor/server/publications/messages.ts:245

): Promise<
	| {
			updated: IMessage[];
			deleted: IMessage[];
			cursor?: {
				next: string | null;
				previous: string | null;
			};
	  }
	| false
	| IMessage[]
	| { messages: IMessage[]; firstUnread?: any; unreadNotLoaded?: number }
> => {
	if (!(await canAccessRoomIdAsync(rid, fromId))) {
		throw new Meteor.Error('error-not-allowed', 'Not allowed', { method: 'messages/get' });
	}

	if (type && !['UPDATED', 'DELETED'].includes(type)) {
		throw new Meteor.Error('error-type-param-not-supported', 'The "type" parameter must be either "UPDATED" or "DELETED"');
	}

	if ((next || previous) && !type) {
		throw new Meteor.Error('error-type-param-required', 'The "type" parameter is required when using the "next" or "previous" parameters');
	}

	if (next && previous) {
		throw new Meteor.Error('error-cursor-conflict', 'You cannot provide both "next" and "previous" parameters');
	}

	if ((next || previous) && lastUpdate) {
		throw new Meteor.Error(
			'error-cursor-and-lastUpdate-conflict',
			'The attributes "next", "previous" and "lastUpdate" cannot be used together',
		);
	}

	// `fromTs` only bounds the query on the `lastUpdate` path; neither cursor pagination nor the channel

View on GitHub (pinned to b2c16d5842)

Solutions

  1. Use the exact strings 'UPDATED' or 'DELETED'
  2. Centralize the allowed values in a constant shared by the client
  3. Trim and validate the parameter before sending when it comes from user input or URLs

Example fix

// before
Meteor.call('messages/get', rid, { type: 'updated', next }); // throws error-type-param-not-supported

// after
Meteor.call('messages/get', rid, { type: 'UPDATED', next });
Defensive patterns

Strategy: validation

Validate before calling

const CURSOR_PAGINATION_TYPES = ['UPDATED', 'DELETED'] as const;
const isCursorPaginationType = (t: unknown): boolean =>
  typeof t === 'string' && (CURSOR_PAGINATION_TYPES as readonly string[]).includes(t);

Type guard

const isCursorPaginationType = (t: unknown): t is 'UPDATED' | 'DELETED' =>
  t === 'UPDATED' || t === 'DELETED';

Prevention

When it happens

Trigger: Passing type: 'updated', 'deleted', 'UPDATE', 'INSERTED', or any other value in a messages/get call (the check runs whenever type is provided, and matters most with cursor pagination).

Common situations: Case typos; clients written against other APIs expecting lowercase enums; exploratory or hand-built requests; query-string whitespace or encoding artifacts around the value.

Understand the failure class

Background: "Invalid query parameter" / "Failed to parse value of ...": fixing bad query string parameters across APIs — this error's family across 36 libraries.

Related errors


AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18). Data as JSON: /api/errors/9bb6cc2ee883ce60. Report an issue: GitHub.