| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 2 | 0% |
| Commands | 0 | 0 | 1 | 0% |
| Section tags | 1 | 0 | 0 | 100% |
What each file covers
Sections
0 shared · 1 only in A · 2 only in B- − ClickHouse Conventions
- + Worker Service
- + Worker Service Conventions
Commands
0 shared · 0 only in A · 1 only in B- + pnpm start:worker
Section tags
1 shared · 0 only in A · 0 only in B- code-style
Line diff
novuhq/novu · .cursor/rules/clickhouse.mdc
@@ −1 @@
1---
2description: Rules for working with ClickHouse analytics and trace logging
3globs:
4 - "**/analytic-logs/**"
5 - "**/clickhouse-migrations/**"
6alwaysApply: false
7---
8
9### ClickHouse Conventions
10
11**Service layer**
12- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14- Never instantiate ClickHouse clients directly — always inject the providers.
15
16**Repositories**
17- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18- Each repository has a corresponding schema file defining the table columns and types.
19- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
20
21**Migrations**
22- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
25
26**Feature flags**
27- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
28
novuhq/novu · .cursor/rules/worker.mdc
@@ +1 @@
1---
2description: Rules for working in the Worker service (background job processing)
3globs: apps/worker/**/*
4alwaysApply: false
5---
6
7## Worker Service
8
9**Stack:** NestJS · Bull + Redis · ClickHouse (execution traces) · cron-parser
10
11**Run:** `pnpm start:worker` — only needed when testing notification triggering; skip for dashboard/API-only tasks.
12
13**Tests/lint:** see testing.mdc
14
15**Key directories:**
16```
17apps/worker/src/app/workflow/usecases/ # Workflow step execution usecases
18apps/worker/src/app/workflow/services/ # Queue consumers and job handlers
19```
20
21---
22
23### Worker Service Conventions
24
25**Use-case structure**
26- Each notification channel has a dedicated `send-message` use-case under `apps/worker/src/app/workflow/usecases/`.
27- Follow the CQRS pattern: `execute(command: CommandClass)` returning a typed result.
28- Keep channel-specific logic isolated — do not share send-message logic across channels.
29
30**Queue / Bull**
31- Job consumers are registered in NestJS modules using Bull's `@Process` decorator.
32- Retry logic and failure handling are configured at the queue level in `libs/application-generic` — do not duplicate this in worker use-cases.
33- Always handle job failures gracefully and log execution details via `CreateExecutionDetails`.
34
@@ −1 +1 @@
11 ---
2−description: Rules for working with ClickHouse analytics and trace logging
3−globs:
4− - "**/analytic-logs/**"
5− - "**/clickhouse-migrations/**"
2+description: Rules for working in the Worker service (background job processing)
3+globs: apps/worker/**/*
64 alwaysApply: false
75 ---
86
9−### ClickHouse Conventions
7+## Worker Service
108
11−**Service layer**
12−- Use `ClickHouseService` for single queries/inserts and `ClickHouseBatchService` for high-throughput writes.
13−- Both are registered as custom providers (`clickHouseService`, `clickHouseBatchService`) in each app's `shared.module.ts`.
14−- Never instantiate ClickHouse clients directly — always inject the providers.
9+**Stack:** NestJS · Bull + Redis · ClickHouse (execution traces) · cron-parser
1510
16−**Repositories**
17−- All ClickHouse repositories extend `LogRepository` in `libs/application-generic/src/services/analytic-logs/`.
18−- Each repository has a corresponding schema file defining the table columns and types.
19−- Always include `_environmentId` and `_organizationId` in queries for tenant isolation (same pattern as MongoDB DAL).
11+**Run:** `pnpm start:worker` — only needed when testing notification triggering; skip for dashboard/API-only tasks.
2012
21−**Migrations**
22−- ClickHouse migrations are numbered `.sql` files in `apps/api/migrations/clickhouse-migrations/`.
23−- Run locally with `cd apps/api && pnpm run clickhouse:migrate:local`.
24−- New migrations must be additive — never alter or drop columns that existing queries depend on. Use temp tables and exchange patterns for schema refactors (see migration 4/5 for the established pattern).
13+**Tests/lint:** see testing.mdc
2514
26−**Feature flags**
27−- Gate new ClickHouse-dependent behavior behind a feature flag (see `packages/shared/src/types/feature-flags.ts` for existing flags like `IS_CLICKHOUSE_BATCHING_ENABLED`).
15+**Key directories:**
16+```
17+apps/worker/src/app/workflow/usecases/ # Workflow step execution usecases
18+apps/worker/src/app/workflow/services/ # Queue consumers and job handlers
19+```
20+
21+---
22+
23+### Worker Service Conventions
24+
25+**Use-case structure**
26+- Each notification channel has a dedicated `send-message` use-case under `apps/worker/src/app/workflow/usecases/`.
27+- Follow the CQRS pattern: `execute(command: CommandClass)` returning a typed result.
28+- Keep channel-specific logic isolated — do not share send-message logic across channels.
29+
30+**Queue / Bull**
31+- Job consumers are registered in NestJS modules using Bull's `@Process` decorator.
32+- Retry logic and failure handling are configured at the queue level in `libs/application-generic` — do not duplicate this in worker use-cases.
33+- Always handle job failures gracefully and log execution details via `CreateExecutionDetails`.
2834
