calcom/cal.diy · error · HttpError

Booking of id ${bookingId} does not exist or does not contai

Error message

Booking of id ${bookingId} does not exist or does not contain daily video as location

What it means

Thrown by getBooking in the daily-webhook handler (HttpError, HTTP 404) when BookingRepository.findByIdWithUserAndEventType(bookingId) returns null. It means no booking exists for that ID, or the booking does not use Daily video as its location. The handler logs the missing bookingId via safeStringify before throwing.

Source

Thrown at apps/web/lib/daily-webhook/getBooking.ts:21

import logger from "@calcom/lib/logger";
import { safeStringify } from "@calcom/lib/safeStringify";
import prisma from "@calcom/prisma";

const log = logger.getSubLogger({ prefix: ["daily-video-webhook-handler"] });

export const getBooking = async (bookingId: number) => {
  const bookingRepository = new BookingRepository(prisma);
  const booking = await bookingRepository.findByIdWithUserAndEventType(bookingId);

  if (!booking) {
    log.error(
      "Couldn't find Booking Id:",
      safeStringify({
        bookingId,
      })
    );

    throw new HttpError({
      message: `Booking of id ${bookingId} does not exist or does not contain daily video as location`,
      statusCode: 404,
    });
  }
  return booking;
};

export type getBookingResponse = Awaited<ReturnType<typeof getBooking>>;

View on GitHub (pinned to 176037d0af)

Solutions

Make the webhook receiver idempotent: treat a 404 'does not exist' as a no-op and return 2xx to stop Daily retries.
Verify the booking's location is daily video before subscribing the webhook to that booking.
If the race is real (webhook before commit), requeue with backoff and retry until the booking appears, with a max-attempt cap.

Example fix

// before
const booking = await getBooking(bookingId); // throws 404

// after
try {
  const booking = await getBooking(bookingId);
  processWebhook(booking);
} catch (e) {
  if (e instanceof HttpError && e.statusCode === 404) {
    return Response.json({ ok: true, ignored: 'booking not found' }); // stop retries
  }
  throw e;
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Idempotent webhook receiver: short-circuit unknown bookings
const booking = await api.getBooking(bookingId).catch(() => null);
if (!booking) {
  return Response.json({ ok: true, ignored: 'booking not found' });
}

Type guard

function isDailyVideoBooking(b: unknown): b is { id: number; location: string } {
  return !!b && typeof b === 'object' &&
    typeof (b as any).id === 'number' &&
    typeof (b as any).location === 'string' &&
    (b as any).location.includes('integrations:daily');
}

Try / catch

try {
  const booking = await getBooking(bookingId);
  await processWebhook(booking);
} catch (e) {
  if (e instanceof HttpError && e.statusCode === 404) {
    return Response.json({ ok: true, ignored: 'not found' }); // stop Daily retries
  }
  throw e;
}

Prevention

Make webhook handlers idempotent and never error out for missing bookings.
Confirm the booking location is daily video before subscribing webhooks.
Cap retries for the booking-not-yet-committed race; otherwise accept-and-ignore.

When it happens

Trigger: A Daily.co webhook fires for a bookingId that has no matching row: deleted/cancelled booking, test webhook with a fake ID, webhook arriving before the booking was committed, or a booking whose location is not daily video.

Common situations: Webhook retry arriving after booking deletion, staging webhook pointing at production IDs, race between booking creation and webhook delivery, non-video bookings erroneously routed to the daily webhook.

Related errors

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