Repository navigation
Make retry queue durable across transient delivery failures #186
Description
Summary
Make the Ruby SDK retry queue durable across transient delivery failures.
Spec
sdk-specs/openspec/specs/retry-queue/spec.md
Current evidence
The SDK audit found that SendWorker removes events from the queue before send and does not requeue on non-200/transient failure.
Expected behavior
- Keep or requeue events after retryable/transient delivery failures.
- Deliver retained events after a later success.
- Bound retained events by queue capacity.
- Drop non-retryable failures appropriately.
- Add tests for 503/network failure retention and later delivery.
Activity
pcbeingused333 commentedon Nov 11, 2026
After transport retries are exhausted,
SendWorkerreports the 503 but unconditionally clears the batch, so those events are unavailable when delivery recovers; a local HTTP receiver returning 503 reproduced this on main9f72706.The retry-queue spec also requires preserving replacement events captured during a successful in-flight flush, so counting all in-flight events against
max_queue_sizeand refusing replacements would conflict with that scenario.Would you prefer merging a failed batch back into the bounded queue with an explicit eviction order when concurrent captures have filled it, or maintaining a separate bounded retry batch?
Either approach would retain retryable failures beyond the transport retry budget, respect cooldowns, discard terminal non-retryable responses, and keep timed flushes and shutdown bounded; if you confirm the capacity policy, I can prepare a PR covering 503/network failure recovery and concurrent captures.
This analysis and proposal were prepared with Codex, an AI coding agent.
posthog commentedon Nov 11, 2026
PostHog self-driving picked up this issue. Status: Research is done.
Somebody may already be working on it, so ask before you start a fix.
Report (team access only): https://us.posthog.com/project/2/inbox/reports/01a1cc43-c8d7-77eb-922d-c1c315b993e9?link_source=github_comment