ingestion-pipeline-doctor-nodejs

作成者: posthog

PostHogのインジェストパイプラインフレームワークとその規約チェックエージェントのクイックリファレンス。

npx skills add https://github.com/posthog/posthog --skill ingestion-pipeline-doctor-nodejs

Pipeline Doctor

Quick reference for PostHog's ingestion pipeline framework and its convention-checking agents.

Architecture overview

The ingestion pipeline processes events through a typed, composable step chain:

Kafka message
  → messageAware()
    → parse headers/body
    → sequentially() for preprocessing
    → filterMap() to enrich context (e.g., team lookup)
    → teamAware()
      → concurrentlyPerGroup(token:distinctId) for per-entity processing
      → gather()
      → pipeChunk() for chunk operations
      → handleIngestionWarnings()
    → handleResults()
  → handleSideEffects()
  → build()

See nodejs/src/ingestion/pipelines/analytics/joined-ingestion-pipeline.ts for the real implementation.

Key file locations

WhatWhere
Step typenodejs/src/ingestion/framework/steps.ts
Result typesnodejs/src/ingestion/framework/results.ts
Doc-test chaptersnodejs/src/ingestion/framework/docs/*.test.ts
Joined pipelinenodejs/src/ingestion/pipelines/analytics/joined-ingestion-pipeline.ts
Doctor agents.claude/agents/ingestion/
Test helpersnodejs/src/ingestion/framework/docs/helpers.ts

Which agent to use

ConcernAgentWhen to use
Step structurepipeline-step-doctorFactory pattern, type extension, config injection, naming
Result handlingpipeline-result-doctorok/dlq/drop/redirect, side effects, ingestion warnings
Compositionpipeline-composition-doctorBuilder chain, concurrency, grouping, branching, retries
Testingpipeline-testing-doctorTest helpers, assertions, fake timers, doc-test style

Quick convention reference

Steps: Factory function returning a named inner function. Generic <T extends Input> for type extension. No any. Config via closure.

Results: Use ok(), dlq(), drop(), redirect() constructors. Side effects as promises in ok(value, [effects]). Warnings as third parameter.

Composition: messageAware wraps the pipeline. handleResults inside messageAware. handleSideEffects after. concurrentlyPerGroup for per-entity work. gather before chunk steps.

Batching lifecycle hooks (BatchingPipeline beforeBatch/afterBatch): enrich-only. Hooks may enrich elements and batch context but must return exactly the elements they received — a count change is a broken invariant and feed() throws. Filtering belongs in sub-pipeline steps that return drop(). An empty feed() is a no-op (no hooks, no capacity). Details: nodejs/src/ingestion/framework/docs/14-batching.test.ts.

Fan-out/fan-in (fanOut(fn).via((sub) => …).fanIn(fn)): per-element sub-work with cardinality restored — one element fans out to N sub-elements (e.g. per-blob uploads), a regular sub-pipeline processes them (maxConcurrency on the sub concurrently block, retry on the per-sub step), and fan-in folds the OK results back into the parent. Reach for it over concurrently/concurrentlyPerGroup when the unit of concurrency is smaller than the element; hand-rolled p-limit/Promise.all inside a step is the tell. Sequencing is compile-time enforced (an unclosed stage cannot build). Sub-result contract: OK collected; DROP excludes the sub silently; DLQ fails the parent with aggregated reasons; REDIRECT is excluded with a warning — sub redirects never escape the stage. Sub-pipelines are context-agnostic: team/message data goes in the sub-element value, and context-gated surface (teamAware, handleIngestionWarnings, …) is uncallable. Fan-out/fan-in functions are cheap, synchronous, and named. Parents emit unordered as they complete. Details: nodejs/src/ingestion/framework/docs/17-fan-out-fan-in.test.ts.

Testing: Step tests call factory directly. Use consumeAll()/collectChunks() helpers. Fake timers for async. Type guards for result assertions. No any.

Running all doctors

Ask Claude to "run all pipeline doctors on my recent changes" to get a comprehensive review across all 4 concern areas.

posthogのその他のスキル

error-tracking-hono
posthog
PostHogのHono向けエラートラッキング
tuning-incremental-sync-config
posthog
同期の設定はExternalDataSchemaに保存され、external-data-schemas-partial-updateを使用していつでも変更できます。ほとんどの変更は非破壊的(次の同期で反映)ですが、一部(sync_typeの切り替え、プライマリキーの変更)は、同期データの破損を防ぐために慎重な対応が必要です。
playwright-test
posthog
Playwrightテストを作成し、それが確実に実行され、かつ不安定でないことを確認してください。
error-tracking-ruby
posthog
PostHogのRuby向けエラートラッキング
authoring-log-alerts
posthog
PostHogプロジェクト内のサービスに対して、有用でノイズの少ないログアラートを作成します。ユーザーがログのアラート設定を依頼したり、追加すべきアラートを提案するよう求めた場合に使用します。
making-scenes-tab-aware
posthog
Guides converting PostHog frontend scenes to be tab aware for internal scene tabs. Use when adding or refactoring a `SceneExport` scene, fixing state leaking…
posthog-survey-creator
posthog
PostHogでガイド付き会話を通じてサーベイを作成・設定します。ユーザーがサーベイを作成したり、ユーザーフィードバックを収集したり、実行したい場合にこのスキルを使用します。
authoring-scouts
posthog
PostHog Signalsスカウト(プロジェクトをスキャンしてSignals受信箱にレポートを書き込むスケジュールエージェント)を作成、編集、適応する方法。ユーザーが…の場合に使用します。