Resolving ingestion warnings

Ingestion warnings record problems PostHog hit while ingesting a project's events. They are the first place to look when events are missing, counts are lower than expected, or identify/merge calls don't behave.

Workflow

1. List the warnings: call posthog:ingestion-warnings-list (defaults to the last 24h; widen with since: '-7d', narrow with severity or type). Each entry has a count, a sparkline, and recent samples with the affected event_uuid / distinct_id / person_id / group_key.
2. Triage by severity — it encodes what happened to the data:
   • error — the event or update was dropped. Data loss; fix these first.
   • warning — ingested, but modified or partially rejected.
   • info — informational, or an intentional, team-configured drop.
3. Route by type using the table below. Where a references/fixing-*.md file exists, read it — it has the full diagnosis and per-SDK fixes; load only the file you need.
4. Verify any fix the same way: re-run the affected flow, re-query posthog:ingestion-warnings-list with a since after the fix, and confirm the type's count stops growing. Warnings are debounced per team+type+key, so judge by "no new occurrences", not by historical counts shrinking.

One identity caveat that applies throughout: distinct IDs are not persons. An identified user usually has several distinct IDs mapping to one person; resolve sampled distinct IDs to persons (posthog:persons-list) before reasoning about patterns.

A second cross-cutting check: SDK version clustering. Pull $lib / $lib_version from the affected events and compare against unaffected traffic — warnings concentrating on old SDK versions or one platform usually mean an outdated or pinned SDK, and the fix is an upgrade rather than payload surgery.