Replace placeholder 403 response with proper ForbiddenErrorResponse type.

The comment indicates this is a placeholder implementation. Since ForbiddenErrorResponse is now exported from rest-typings, use it instead of the never type with a manual schema.

Apply this fix to use the proper type:

+import {
+	ForbiddenErrorResponse,
+	// ... other imports
+} from '@rocket.chat/rest-typings';

 // In dmCloseEndpointsProps:
-		// TODO: The 403 Forbidden response is not handled as well as 400 responses.
-		//       Currently using `never` as a placeholder type. Replace it with the correct
-		//       schema once proper 403 error handling is implemented.
-		403: ajv.compile<never>({
-			type: 'object',
-			properties: {
-				success: { type: 'boolean', enum: [false] },
-				status: { type: 'string' },
-				message: { type: 'string' },
-				error: { type: 'string' },
-				errorType: { type: 'string' },
-			},
-			required: ['success'],
-			additionalProperties: false,
-		}),
+		403: ajv.compile<ForbiddenErrorResponse>({
+			type: 'object',
+			properties: {
+				success: { type: 'boolean', enum: [false] },
+				status: { type: 'string' },
+				message: { type: 'string' },
+				error: { type: 'string' },
+				errorType: { type: 'string' },
+			},
+			required: ['success'],
+			additionalProperties: false,
+		}),

🌐 Web query:

What is the correct way to handle 403 Forbidden responses in OpenAPI with TypeScript and AJV validation?

💡 Result:

Short answer

• Declare a dedicated 403 response schema in your OpenAPI operation (or a shared component and/or default error schema). Then validate the actual response body against the schema for the response's HTTP status (not against the 200 schema). Use your runtime validator or AJV to pick the schema keyed by status and validate that one. This prevents a 403 being forced to match the success (200/201) schema. [1][2][3]

Why

• OpenAPI responses are indexed by status code (and default). A 403 must have its own entry if you expect a structured body for that status; otherwise the validator has no correct schema to check. Many OpenAPI response validators validate responses only against the schema for the returned status (or default). Configure your validator to do that. [1][2][4]

Minimal examples

1. OpenAPI fragment (YAML)
   components:
   schemas:
   ErrorResponse:
   type: object
   properties:
   code:
   type: string
   message:
   type: string
   required: [code, message]

paths:
/items/{id}:
get:
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/Item'
'403':
description: Forbidden
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
default:
description: Other errors
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'

2. TypeScript + AJV runtime approach (conceptual)

• Generate or extract JSON Schemas for responses (per operation/status).
• At runtime, after receiving response:
  • const schema = responseSchemas[operationId][String(status) || 'default'];
  • const valid = ajv.validate(schema, body);
  • if (!valid) handle validation error (log/throw/transform).
    This makes sure a 403 response is validated only against the 403 ErrorResponse schema. [3][5]

Practical notes / gotchas

• Place shared error structure in components/schemas and reference it for 4xx/5xx entries. [1]
• If using a middleware (express-openapi-validator, openapi-response-validator, codegen libraries), enable response validation and ensure it validates by status. Many libraries offer validateResponses and options to customize behavior. [4][6]
• If you see a 403 failing against the 200 schema, you’re either (a) missing a 403/default response schema in the OpenAPI doc, or (b) your validator is configured incorrectly (validating against the wrong schema or only the 200). Fix the OpenAPI doc or validator config. [4][6]

References

1. OpenAPI errors / response guidance. [Speakeasy / OpenAPI errors]. [2]
2. openapi-typescript-validator (generate TS + AJV decoders from OpenAPI schemas). [openapi-typescript-validator README]. [3]
3. openapi-response-validator (validates responses per status schema). [openapi-response-validator]. [5]
4. express-openapi-validator docs — validateResponses option and behavior. [express-openapi-validator documentation]. [6]

If you want, I can: (a) inspect your OpenAPI file and point out missing 403/default entries, or (b) produce a small TypeScript/AJV code sample wired to your generated schemas.

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Searching repo for 'ForbiddenErrorResponse'..."
rg -n --hidden --no-ignore -S "ForbiddenErrorResponse" || true

echo
echo "Searching repo for imports from '@rocket.chat/rest-typings'..."
rg -n --hidden --no-ignore -S "@rocket.chat/rest-typings" || true

TARGET="apps/meteor/app/api/server/v1/im.ts"
echo
if [ -f "$TARGET" ]; then
  echo "Showing $TARGET (lines 150-200):"
  nl -ba -w4 -s": " "$TARGET" | sed -n '150,200p'
else
  echo "$TARGET not found"
fi

echo
echo "Searching for occurrences of 'ajv.compile<never>'..."
rg -n --hidden --no-ignore -S "ajv.compile<never>" || true

echo
echo "Searching for '403: ajv.compile' patterns..."
rg -n --hidden --no-ignore -S "403: ajv.compile" || true

echo
echo "Searching package.json files for '@rocket.chat/rest-typings'..."
rg -n --hidden --no-ignore -S "\"@rocket.chat/rest-typings\"" || true

Length of output: 227718