Summary
Improve retry queue behavior and define backpressure/overflow semantics.
Why
sdk-specs marks retry-queue and event-batcher as applicable to both client and server SDKs. Backend SDKs should retain retryable failed deliveries and make queue overflow behavior explicit.
Current status
PostHog.Sender batches by size/time, but after PostHog.API.batch/2 the sender clears state regardless of HTTP result. There is no durable/in-memory retry queue behavior for retryable failures, and no explicit full-queue/backpressure policy was found.
Python has a related queue/backpressure issue: PostHog/posthog-python#146.
Suggested scope
- Retain events when delivery fails with retryable network/5xx/429-style errors.
- Drop or acknowledge non-retryable failures according to documented policy.
- Define queue capacity and overflow behavior: drop oldest/newest vs block/backpressure.
- Emit warnings/telemetry/metrics when events are dropped or retrying.
- Serialize concurrent flushes and preserve FIFO best effort.
- Add tests for success, retryable failure, non-retryable failure, and overflow.
References
Summary
Improve retry queue behavior and define backpressure/overflow semantics.
Why
sdk-specsmarksretry-queueandevent-batcheras applicable to both client and server SDKs. Backend SDKs should retain retryable failed deliveries and make queue overflow behavior explicit.Current status
PostHog.Senderbatches by size/time, but afterPostHog.API.batch/2the sender clears state regardless of HTTP result. There is no durable/in-memory retry queue behavior for retryable failures, and no explicit full-queue/backpressure policy was found.Python has a related queue/backpressure issue: PostHog/posthog-python#146.
Suggested scope
References