What causes "err.getResponse()" in calcom/cal.diy?

This is a pass-through — the real error is the underlying HttpException. Check the response body for the original message and status code.

calcom/cal.diy · error · HttpException

err.getResponse()

Error message

err.getResponse()

What it means

This is the re-throw path inside handleBookingErrors when the caught error is both an instance of Error and specifically a NestJS HttpException (e.g., BadRequestException, NotFoundException, ForbiddenException thrown by the controller's own checkBookingRequiresAuthentication or nested services). The handler preserves the exact original response body and status code by calling getResponse() and getStatus().

Source

Thrown at apps/api/v2/src/platform/bookings/2024-04-15/controllers/bookings.controller.ts:599

  }

  private handleBookingErrors(
    err: Error | HttpError | unknown,
    type?: "recurring" | `instant` | "no-show"
  ): void {
    const errMsg =
      type === "no-show"
        ? `Error while marking no-show.`
        : `Error while creating ${type ? `${type} ` : ""}booking.`;
    if (err instanceof HttpError) {
      const httpError = err as HttpError;
      throw new HttpException(httpError?.message ?? errMsg, httpError?.statusCode ?? 500);
    }

    if (err instanceof Error) {
      const error = err as Error;
      if (err instanceof HttpException) {
        throw new HttpException(err.getResponse(), err.getStatus());
      }
      if (Object.values(ErrorCode).includes(error.message as unknown as ErrorCode)) {
        throw new HttpException(error.message, 400);
      }
      throw new InternalServerErrorException(error?.message ?? errMsg);
    }

    throw new InternalServerErrorException(errMsg);
  }

  private transformToBoolean(v?: string): boolean {
    return v && typeof v === "string" ? v.toLowerCase() === "true" : false;
  }
}

View on GitHub (pinned to 176037d0af)

Solutions

This is a pass-through — the real error is the underlying HttpException. Check the response body for the original message and status code.
If you see a 401/403, follow the guidance for errors 242/243 respectively.
If you see a 400 from checkBookingRequiresAuthentication, follow the guidance for error 241.
No code change is needed in the controller — this path correctly preserves error details.

Defensive patterns

Strategy: try-catch

Try / catch

// This is a pass-through of the original HttpException — handle by status code
try {
  await api.createBooking(payload);
} catch (err) {
  // err.statusCode and err.message reflect the original HttpException
  if (err.statusCode === 401) handleAuth();
  else if (err.statusCode === 403) handleForbidden();
  else if (err.statusCode === 400) handleBadRequest(err.message);
  else throw err;
}

Prevention

This path preserves the original exception — treat the status code as authoritative.
Don't wrap booking API calls in broad catch-and-retry — the original error is intentional and informative.
Structure client error handling around HTTP status codes rather than message strings.

When it happens

Trigger: An HttpException thrown earlier in the same controller method (e.g., checkBookingRequiresAuthentication throws UnauthorizedException or ForbiddenException) is caught by the try/catch in createBooking, cancelBooking, createRecurringBooking, or markNoShow, and routed through handleBookingErrors. This path ensures the original Nest exception details are not lost.

Common situations: The controller's own auth/authorization checks (errors 241-243) throw NestJS HttpExceptions that get caught by the surrounding try/catch and funneled through handleBookingErrors. Also happens when a nested NestJS service throws an HttpException that propagates upward. The response body (which may be an object with message and error fields) is preserved exactly.

Related errors

AI-assisted analysis of calcom/cal.diy@176037d0af (2026-08-12). Data as JSON: /api/errors/7552513fcd94159f. Report an issue: GitHub.