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

Retry the GET after a short delay to absorb read-replica lag.

calcom/cal.diy · error · NotFoundException

Event type with id ${eventTypeCreated.id} not found

Error message

Event type with id ${eventTypeCreated.id} not found

What it means

Thrown by EventTypesService_2024_06_14.createUserEventType (POST /v2/event-types, cal-api-version 2024-06-14) immediately after a create+update sequence, when the follow-up getEventTypeById returns null. The row was reportedly created and updated but cannot be re-read — a post-create consistency failure indicating a race, a transaction rollback, or a repository filter excluding the new row.

Source

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

        prisma: this.dbWrite.prisma,
      },
    });

    await updateEventType({
      input: {
        id: eventTypeCreated.id,
        ...body,
      },
      ctx: {
        user: eventTypeUser,
        prisma: this.dbWrite.prisma,
      },
    });

    const eventType = await this.eventTypesRepository.getEventTypeById(eventTypeCreated.id);

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

    return {
      ownerId: user.id,
      ...eventType,
    };
  }

  async getEventTypeByIdIfAuthorized(
    authUser: ApiAuthGuardUser,
    eventTypeId: number
  ): Promise<DatabaseTeamEventType | ({ ownerId: number } & DatabaseEventType) | null> {
    const eventType = await this.eventTypesRepository.getEventTypeByIdWithHosts(eventTypeId);

    if (!eventType) {
      return null;
    }

View on GitHub (pinned to 176037d0af)

Solutions

Retry the GET after a short delay to absorb read-replica lag.
Check whether the create actually persisted by listing the user's event types.
Inspect createEventType and updateEventType for transaction boundaries that may roll back after returning an id.
If reproducible, verify the read and write Prisma clients point at the same primary or a low-lag replica.

Example fix

// before
const created = await api.post('/v2/event-types', body); // throws 404 internally
// after
let created;
try {
  created = await api.post('/v2/event-types', body);
} catch (e) {
  if (e.response?.status === 404) {
    // likely read-after-write lag; verify via list
    const list = (await api.get('/v2/event-types')).data;
    created = list.find(e => e.slug === body.slug);
  }
  if (!created) throw e;
}

Defensive patterns

Strategy: retry

Try / catch

try {
  return await api.post('/v2/event-types', body, { headers: { 'cal-api-version': '2024-06-14' } });
} catch (e) {
  if (e.response?.status === 404) {
    // post-create read failed; verify via list to avoid duplicate creates
    const list = (await api.get('/v2/event-types', { headers: { 'cal-api-version': '2024-06-14' } })).data;
    const found = list.find((x) => x.slug === body.slug);
    if (found) return found;
  }
  throw e;
}

Prevention

On a 404 from create, list event types before retrying to avoid duplicate rows.
If using read replicas, accept that post-create reads may lag — build in a single retry.
Inspect createEventType/updateEventType transaction boundaries if this is reproducible.

When it happens

Trigger: createEventType succeeds and returns an id, then updateEventType runs, but the subsequent getEventTypeById returns null because: the create was rolled back by a downstream hook; the read replica lags; a Prisma transaction aborted after returning the id; the new row is filtered out by a soft-delete or org scope in getEventTypeById.

Common situations: Read-replica lag in a distributed deployment; an after-create hook that soft-deletes or moves the row; a transaction isolation level that hides uncommitted rows from the read client; a bug where createEventType returns a phantom id on validation failure.

Related errors

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