RocketChat/Rocket.Chat · warning · Error

The "${name}" parameter must be a valid date.

Error message

The "${name}" parameter must be a valid date.

What it means

Thrown by parseDateOrFail in the audit.auditions endpoint handler when Date.parse() returns NaN for the startDate or endDate query parameter. The helper is called for both queryParams.startDate and queryParams.endDate; the failing parameter name is interpolated into the message so the caller knows which one is malformed.

Source

Thrown at apps/meteor/ee/server/api/audit.ts:404

	},
	required: ['messages', 'success'],
	additionalProperties: false,
});

const auditErrorResponseSchema = ajv.compile({
	type: 'object',
	properties: {
		success: { type: 'boolean', enum: [false] },
		error: { type: 'string' },
		errorType: { type: 'string' },
	},
	required: ['success', 'error'],
});

const parseDateOrFail = (value: string, name: string): Date => {
	const ts = Date.parse(value);
	if (Number.isNaN(ts)) {
		throw new Error(`The "${name}" parameter must be a valid date.`);
	}
	return new Date(ts);
};

API.v1.get(
	'audit.auditions',
	{
		authRequired: true,
		permissionsRequired: ['can-audit-log'],
		query: isAuditAuditionsProps,
		license: ['auditing'],
		rateLimiterOptions: { numRequestsAllowed: 10, intervalTimeInMS: 60000 },
		response: {
			200: auditAuditionsResponseSchema,
			400: auditErrorResponseSchema,
			401: validateUnauthorizedErrorResponse,
			403: validateForbiddenErrorResponse,
		},

View on GitHub (pinned to f9d3ec372b)

Solutions

  1. Send startDate/endDate as full ISO-8601 strings with timezone (e.g. '2024-01-01T00:00:00.000Z').
  2. Validate/normalize the date client-side before the request and fall back to a sane default.
  3. If relative ranges are needed, compute the ISO string in code, do not pass words like 'yesterday'.

Example fix

// before
GET /api/v1/audit.auditions?startDate=yesterday&endDate=2024-01-01

// after
const start = new Date(Date.now() - 86400000).toISOString();
const end = new Date().toISOString();
GET `/api/v1/audit.auditions?startDate=${start}&endDate=${end}`
Defensive patterns

Strategy: validation

Validate before calling

// Validate ISO date strings before calling audit.auditions.
const isValidDate = (v: string) => !Number.isNaN(Date.parse(v));
if (!isValidDate(startDate) || !isValidDate(endDate)) {
  throw new Error('startDate and endDate must be valid ISO-8601 dates');
}
GET `/api/v1/audit.auditions?startDate=${encodeURIComponent(new Date(startDate).toISOString())}&endDate=${encodeURIComponent(new Date(endDate).toISOString())}`

Type guard

const isParseableDate = (v: unknown): v is string =>
  typeof v === 'string' && !Number.isNaN(Date.parse(v));

Try / catch

try {
  await fetch(`/api/v1/audit.auditions?startDate=${start}&endDate=${end}`);
} catch (e) {
  if (/must be a valid date/.test(e?.message)) { /* normalize inputs to ISO and retry */ }
  else throw e;
}

Prevention

When it happens

Trigger: Calling GET /api/v1/audit.auditions with a startDate or endDate that is not ISO-8601/RFC2822 parseable (e.g. '2024-13-45', 'yesterday', empty string, 'NaN'); passing a numeric timestamp as a non-string; localized date format Date.parse cannot handle.

Common situations: Client sends locale-formatted dates (DD/MM/YYYY) instead of ISO; empty/null date params; copy-paste typo; timezone-less relative strings.

Related errors

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