calcom/cal.diy · error · InternalServerErrorException

errMsg

Error message

errMsg

What it means

This is the final fallback message inside handleBookingErrors for the 'unknown' error type — when the caught value is neither an HttpError nor an Error instance. This happens when something non-standard is thrown (a string, number, plain object, null, or undefined). The handler throws a 500 InternalServerErrorException with only the contextual errMsg, since there's no .message property to extract.

Source

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

        ? `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

  1. Search the booking service codebase for bare 'throw' statements that throw non-Error values and replace them with throw new Error(...).
  2. Check third-party integration code (app-store apps) for non-Error throws.
  3. Add logging before this throw to capture the actual value of err (e.g., JSON.stringify or util.inspect) for debugging.
  4. If you see this in production, reproduce locally with verbose logging to capture the non-Error value's shape.

Example fix

// before — non-Error throw somewhere in the pipeline
if (!slot) throw 'No slot available';

// after — proper Error
if (!slot) throw new Error('No slot available');
Defensive patterns

Strategy: try-catch

Try / catch

try {
  await api.createBooking(payload);
} catch (err) {
  if (err.statusCode === 500 && err.message.startsWith('Error while')) {
    // This is the unknown-type fallback — minimal diagnostic info available
    console.error('Unhandled error type in booking flow. Request:', payload);
    // Report to Cal.com with the request details for investigation
  } else { throw err; }
}

Prevention

When it happens

Trigger: Code somewhere in the booking pipeline does throw 'some string' or throw { code: 123 } instead of throwing a proper Error subclass. Also triggered if a Promise rejection reason is a non-Error value, or if a library internally throws a non-Error.

Common situations: A third-party library or app-store integration throws a non-Error value. Internal code that was quickly written with throw 'message' instead of throw new Error('message'). A Promise.reject('reason') without wrapping in Error. This path loses all diagnostic detail since only the generic errMsg is available.

Related errors


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