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
- Search the booking service codebase for bare 'throw' statements that throw non-Error values and replace them with throw new Error(...).
- Check third-party integration code (app-store apps) for non-Error throws.
- Add logging before this throw to capture the actual value of err (e.g., JSON.stringify or util.inspect) for debugging.
- 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
- If you're a platform developer, never throw non-Error values — always use throw new Error(...) or a subclass.
- Audit app-store integrations for non-Error throws.
- Add server-side logging before the final fallback throw to capture the actual error value.
- Report recurring instances of this error to Cal.com — it indicates a code quality issue in the pipeline.
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
- error?.message ?? errMsg
- Could not create recurring booking.
- httpError?.message ?? errMsg
- err.getResponse()
- error.message
AI-assisted analysis of calcom/cal.diy@176037d0af (2026-08-12).
Data as JSON: /api/errors/0efebab6b8790768.
Report an issue: GitHub.