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 channelView on GitHub (pinned to b2c16d5842)
Solutions
- Use the exact strings 'UPDATED' or 'DELETED'
- Centralize the allowed values in a constant shared by the client
- 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
- Share a single constant of allowed type values between client and server
- Reject unvalidated type values from user input before they reach the API call
- Remember the check is case-sensitive: 'UPDATED'/'DELETED' only
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
- error-type-param-required
- error-cursor-conflict
- Invalid Date
- error-cursor-not-found
- error-cursor-and-lastUpdate-conflict
AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18).
Data as JSON: /api/errors/9bb6cc2ee883ce60.
Report an issue: GitHub.