feat(rust): upgrade workspace to posthog-rs 0.18.0 and on_error metric

[eli-r-ph]

Problem

When a posthog-rs capture, /flags, or local-evaluation request fails terminally (retries exhausted or a permanent reject), our Rust services only emit a log line. There is no metric, so we cannot alert on the internal telemetry pipeline silently dropping events during an outage.

The workspace was also stuck on a split posthog-rs: everything ran 0.13.3, and batch-import-worker could not move forward because 0.14.0 made batch capture fire-and-forget, dropping the synchronous delivery Result the import commit path relies on to gate Kafka offset rollback (its at-least-once guarantee).

posthog-rs 0.18.0 unblocks both at once. 0.17.0 added the on_error observability hook, and 0.18.0 (PostHog/posthog-rs#175) restores an awaited, Result-returning batch capture (capture_batch_immediate). So we can unify the whole workspace on one version and get the failure signal.

Changes

• Upgrade the workspace posthog-rs to 0.18.0 and drop batch-import-worker's separate 0.13.3 pin, so the entire Rust workspace now resolves a single posthog-rs version (verified: Cargo.lock collapses two entries to one).
• Register on_error in common_posthog::init, emitting posthog_sdk_delivery_failures_total labeled service / surface (capture, flags, local_evaluation) / reason (bounded failure class). The reason split mirrors the worker's existing failure_reason so quota (expected billing enforcement) stays separable from actionable transport/server failures. The service label keeps the shared metric faceted per service.
• cymbal: capture has been non-blocking since 0.14, so the old spawning_capture (spawn a task, await, log on error) collapses to a direct fire_capture. The on_error hook now owns the failure signal it used to log.
• batch-import-worker: capture_batch -> capture_batch_immediate. This is compile-forced, not cosmetic: in 0.18.0 capture_batch is fire-and-forget (non-async, returns nothing). capture_batch_immediate reuses the identical v1 Ok/Err response classification, so the worker's offset gating and success/failure metrics are unchanged.

Companion Grafana dashboard PR: PostHog/grafana-dashboards#231.

How did you test this code?

Automated tests I (actually Claude, in Cursor) ran under flox, all passing:

• cargo build + cargo clippy --all-targets + cargo fmt --check for batch-import-worker, common-posthog, cymbal — clean (only a pre-existing celes future-incompat note, unrelated).
• cargo test -p batch-import-worker — the 21 emit::capture tests are the parity gate and pass verbatim against capture_batch_immediate: test_commit_write_fails_immediately_on_400, _fails_on_402_billing_limit, _retries_on_500_then_succeeds, _exhausts_retries_on_persistent_500, quota_failure_is_separable_from_actionable_failures, bad_request_failure_labels_events_and_requests, success_counts_events_total_and_requests_per_subbatch. These assert the exact offset-rollback and metric outcomes per HTTP status, so a green run proves behavior is identical to the 0.13.3 pin.
• cargo test -p common-posthog — sdk_error_reason_maps_every_variant (the alerting contract: quota stays separable) and on_error_hook::init_hook_emits_delivery_failure_metric_on_terminal_reject (drives a real client through init against a mock server returning 400, asserts the metric fired exactly once with the right labels).

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

No user-facing docs affected (internal service telemetry only).

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Directed by @eli-r-ph; implemented by Claude (Cursor). Key decisions:

• Gated the whole upgrade on 0.18.0 actually publishing — verified it live on crates.io and confirmed the downloaded .crate exposes both capture_batch_immediate and the on_error hook before touching the workspace.
• Proved the bump is safe rather than assuming it: the public-API delta 0.17.0 -> 0.18.0 is purely additive (CaptureSummary, capture_immediate, capture_batch_immediate, a new secret_key builder), nothing this PR relies on was removed or changed.
• Proved worker parity from source: 0.13.3 capture_batch and 0.18.0 capture_batch_immediate drive the identical v1 after_response classification (is_retryable_status and Error::from_http_response are byte-identical across the two tags), so Err (roll back the offset) and Ok (advance) fire on exactly the same responses. The worker ignored the old Ok(()) payload and ignores the new Ok(CaptureSummary) the same way.
• Kept the worker on the synchronous Result and deliberately did NOT route it through on_error: the hook fires post-return on a background thread and cannot gate a Kafka offset. on_error is for the fire-and-forget crates (cymbal, embedding-worker) only.
• No repo skills applied (no migrations, DRF, or frontend touched).

[greptile-apps]

_{Reviews (1): Last reviewed commit: "feat(observability): surface posthog-rs ..." | Re-trigger Greptile}

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[greptile-apps]

_{Reviews (2): Last reviewed commit: "feat(rust): migrate batch-import-worker ..." | Re-trigger Greptile}

[cat-ph]

🚀

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-07-10 18:55 UTC	Run
prod-us	✅ Deployed	2026-07-10 19:06 UTC	Run
prod-eu	✅ Deployed	2026-07-10 19:07 UTC	Run