Repository navigation
Conversation
With capture_mode="v1", 404 and 429 now retry like 408 and the 5xx statuses, with the same backoff, Retry-After handling and retry budget. They raise CaptureV1Error with their status after the last attempt. This matches the v1 branch (#1132) and the harness capture v1 retry_behavior suite.
5 of 6 tasks
Contributor
posthog-python Compliance ReportDate: 2026-11-06T09:07:44.502363+00:00 ✅ All Tests Passed!121/121 tests passed Capture_V1 Tests✅ 95/95 tests passed View Details
Capture_Ai Tests✅ 5/5 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
Feature_Flags_Local_Evaluation Tests✅ 4/4 tests passed View Details
|
…leep Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Not approved — escalated to a human reviewer.
Re-add the stamphog label to request another review once you have addressed this.
The change enters data-ingestion territory without independent assurance; no current-head reviews, owning-team membership, or STRONG familiarity are reported. Request review from a teammate or agent reviewer before re-requesting, with Eli Reisman or Manoel Aranda Neto suggested based on familiarity.
- Author wrote 0% of the modified lines and has 5 merged PRs in these paths (familiarity MODERATE).
- Risky territory without independent assurance: Data ingestion or write paths — posthog/capture_v1.py changes event-delivery behavior so HTTP 404 and 429 responses retry the pending batch using the existing backoff and retry budget instead of failing immediately.
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 9L, 1F substantive, 37L/4F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1b-small (37L, 4F, two-areas, fix) |
| stamphog 2.7.0 | .stamphog/policy.yml @ 6e7aa13 · reviewed head 6e7aa13 |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
💡 Motivation and Context
With
capture_mode="v1", the SDK fails a batch at once when capture returns404or429. The v1 release line has retried both since #1132. The capture v1 suites in the SDK test harness check this too:retry_behavior.retries_on_404andretries_on_429were added in PostHog/posthog-sdk-test-harness#92 and released in 1.24.0. Main's v1 mode fails both tests, so this repo's compliance workflow cannot move its harness pin past 1.23.0.This ports the status change from #1132 to
posthog/capture_v1.pyon main:_RETRYABLE_STATUSESadds404and429, and they leave_TERMINAL_STATUSES. They use the same backoff,Retry-Afterhandling and retry budget as408and the 5xx statuses. After the last attempt,CaptureV1Erroris raised with their status.404,429and503. The terminal-status test uses402in place of429.AGENTS.mdno longer lists "terminal v1429" as a rule to keep.patchchangeset describes the change.v0 capture does not change. It already retries
429, and it does not retry404.Spec: PostHog/sdk-specs#146 (open) specifies capture v1 delivery for every v1 SDK. It says a v1 SDK SHALL retry
404,408,429,500,502,503and504, and it records the 2026-10-27 decision to retry404and429. Theretry-queuespec on sdk-specs main already lists429as retryable.This PR matches #1132 and PostHog/sdk-specs#146 on which statuses are retried, but not on timing. Main keeps its 1, 2, 4 second backoff (capped at 30 seconds, with
Retry-Afteras a floor). #1132 and the spec wait 100, 200, 400 ms with ±25% jitter. This PR does not change timing.💚 How did you test it?
pytest posthog/test/test_capture_v1.py: 102 passed. The four new404and429cases fail without the fix. The exhaustion cases also checkattempts == 2and exactly one 1 second sleep, with no sleep after the final attempt.pytest --timeout=30: everything passes except 3 fork tests intest_metrics_autocapture.py. They pass when that file runs alone, both with and without this change.ruff format --check .,ruff check .,mypy ... | mypy-baseline filterandpython -W error -c "import posthog"pass.retries_on_404andretries_on_429Without this change, v1 fails exactly those two tests.
📝 Checklist
If releasing new changes
sampo addto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Authored with Claude Code, directed by @andehen. The change copies the status sets and tests from #1132 on the v1 branch, so the two lines agree. This PR does not move the harness pin. That can follow once this merges.
🤖 Generated with Claude Code