fix(traces): give traces ingestion its own rate-limiter key and wire TRACES_LIMITER_* config

[jonmcwest]

Problem

The TracesIngestionConsumer extends LogsIngestionConsumer and reuses its token-bucket rate limiter infrastructure. Before this change, both consumers wrote their per-team rate-limit state to the same Redis key namespace (@posthog/logs-rate-limiter). This meant traces traffic could deplete a team's logs rate-limit bucket (and vice versa), causing incorrect throttling across two unrelated ingestion pipelines.

Additionally, the LogsIngestionConsumer constructor was applying overrides inconsistently — some fields used overrides.X ?? config.X and others read directly from config, making it easy to silently miss an override (which is exactly how the rate limiter ended up ignoring the traces-specific config values).

Changes

• LogsRateLimiterService now accepts an optional limiterName parameter. The Redis key prefix is derived from this name via a new buildBaseRedisKey helper, so logs and traces get isolated namespaces (logs-rate-limiter vs traces-rate-limiter).
• LogsIngestionConsumer merges config and overrides into a single mergedConfig object at construction time, eliminating the scattered overrides.X ?? config.X pattern and ensuring all downstream services (including the rate limiter) see the correct effective config.
• TracesIngestionConsumer passes 'traces-rate-limiter' as the limiter name to super(...), giving it its own isolated per-team token buckets.

How did you test this code?

New automated tests cover:

• LogsRateLimiterService key namespacing: verifies the default prefix is logs-rate-limiter and that passing 'traces-rate-limiter' produces a distinct, non-overlapping prefix.
• TracesIngestionConsumer rate limiter isolation: verifies the consumer's rate limiter uses the traces-rate-limiter key namespace and that TRACES_LIMITER_* config values are correctly forwarded through the merged config to the rate limiter.

Automatic notifications

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

Docs update

[jonmcwest]

• fix(traces): give traces ingestion its own rate-limiter key and wire TRACES_LIMITER_* config #60673 👈 (View in Graphite)
• feat(traces): switch traces billing metrics to traces_mb_ingested #60655
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

Focused bug fix that gives traces ingestion its own Redis key namespace for rate limiting so token buckets don't bleed across ingestion types. Code is clean, logic is sound, and new tests verify the isolation. No production risk beyond the intentional behavioral change (which is the fix).

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
nodejs/src/logs-ingestion/services/logs-rate-limiter.service.test.ts:834-845
**Prefer a parameterised test for key-namespacing cases**

These two `it` blocks are the same assertion structure with different inputs (`limiterName` and expected prefix). The team prefers parameterised tests; a single `it.each` would express the same coverage more concisely and make it easy to add a third limiter in the future without duplicating the scaffold.

_{Reviews (1): Last reviewed commit: "fix(traces): give traces ingestion its o..." | Re-trigger Greptile}

New commits pushed (delta classified non_linear_history) — stamphog approval dismissed; re-review running automatically.

[github-actions]

Clean bug fix that isolates traces rate-limiter Redis key namespace from logs, with a straightforward mergedConfig refactor and new tests covering both the namespace isolation and config wiring. The one bot comment about parameterized tests was already addressed in the current diff.

[stamphog]

Retaining stamphog approval — delta since last review classified as trivial_paths.

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-06-01 15:42 UTC	Run
prod-us	✅ Deployed	2026-06-01 15:57 UTC	Run
prod-eu	✅ Deployed	2026-06-01 16:00 UTC	Run