What causes "Event type with id ${eventTypeId} not found" in calcom/cal.diy?

Retry the PATCH once after a short delay if you suspect read-replica lag.

calcom/cal.diy · error · NotFoundException

Event type with id ${eventTypeId} not found

Error message

Event type with id ${eventTypeId} not found

What it means

Thrown by EventTypesService_2024_04_15.updateEventType (PATCH /v2/event-types/:eventTypeId) after a successful updateEventType library call, when the subsequent getUserEventTypeForAtom returns null. This is a post-update consistency check: the row was updated but can no longer be read as belonging to the authenticated user — a race or ownership-shift condition.

Source

Thrown at apps/api/v2/src/platform/event-types/event-types_2024_04_15/services/event-types.service.ts:160

        type: BaseField.email,
        editable: Editable.systemButOptional,
      });
    }

    await updateEventType({
      input: { id: eventTypeId, ...body, bookingFields },
      ctx: {
        user: eventTypeUser,
        // eslint-disable-next-line @typescript-eslint/ban-ts-comment
        // @ts-ignore
        prisma: this.dbWrite.prisma,
      },
    });

    const eventType = await this.getUserEventTypeForAtom(user, eventTypeId);

    if (!eventType) {
      throw new NotFoundException(`Event type with id ${eventTypeId} not found`);
    }

    return eventType.eventType;
  }

  async checkCanUpdateEventType(userId: number, eventTypeId: number) {
    const existingEventType = await this.getUserEventType(userId, eventTypeId);
    if (!existingEventType) {
      throw new NotFoundException(`Event type with id ${eventTypeId} not found`);
    }
    this.checkUserOwnsEventType(userId, existingEventType);
  }

  async getUserToUpdateEvent(user: UserWithProfile) {
    const profileId = this.usersService.getUserMainProfile(user)?.id || null;
    const selectedCalendars = await this.selectedCalendarsRepository.getUserSelectedCalendars(user.id);
    const eventTypeSelectedCalendars =
      await this.selectedCalendarsRepository.getUserEventTypeSelectedCalendar(user.id);

View on GitHub (pinned to 176037d0af)

Solutions

Retry the PATCH once after a short delay if you suspect read-replica lag.
Confirm no concurrent delete is running on the same eventTypeId.
Verify the authenticated user still owns the event type (or is still an org admin) via GET /v2/event-types/:eventTypeId.
If reproducible, inspect the updateEventType library call for a field that inadvertently resets userId.

Example fix

// before
const updated = await api.patch(`/v2/event-types/${id}`, body);
// after
await api.patch(`/v2/event-types/${id}`, body);
let updated;
try {
  updated = await api.get(`/v2/event-types/${id}`);
} catch (e) {
  if (e.response?.status === 404) throw new Error('event type disappeared after update; possible concurrent delete');
  throw e;
}

Defensive patterns

Strategy: retry

Try / catch

try {
  return await api.patch(`/v2/event-types/${id}`, body);
} catch (e) {
  if (e.response?.status === 404) {
    // post-update read failure — retry once after a short delay
    await new Promise((r) => setTimeout(r, 200));
    return await api.get(`/v2/event-types/${id}`);
  }
  throw e;
}

Prevention

Avoid concurrent PATCH and DELETE on the same eventTypeId.
After PATCH, fall back to a GET to confirm the update rather than trusting the PATCH response alone.
If using read replicas, route post-write reads to the primary or accept eventual consistency with retries.

When it happens

Trigger: PATCH succeeds, but between the update and the re-read the event type is deleted by another session, transferred to a different user, or the authenticated user's org admin status is revoked; the update silently nullified userId; a transaction isolation issue where the read replica lags behind the writer.

Common situations: Two admin sessions editing concurrently — one deletes while the other patches; org membership changes mid-request; read-replica lag in a distributed DB; a bug in updateEventType that clears the userId field.

Related errors

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