feat(traces): span batch transport

[turnipdabeets]

💡 Motivation and Context

Adds the HTTP transport: one gzipped OTLP JSON POST per batch to {host}/i/v1/traces with bearer auth. Responses are classified as:

• ok: 2xx
• too large: 413, or a body over the 10 MiB hosted ingestion limit (refused without a request)
• retriable: 408, 429, 5xx, transport errors, carrying any Retry-After as delta-seconds or HTTP-date
• fatal: other 4xx

Not reachable from the client yet.

Stack (PR 4 of 9, based on traces/03-span-handles):

1. feat(traces): W3C trace context ids and traceparent parsing #949 traces/01-ids-traceparent
2. feat(traces): OTLP span encoding and client-side validity #950 traces/02-otlp-encoding
3. feat(traces): span handles #951 traces/03-span-handles
4. feat(traces): span batch transport #952 traces/04-transport ← this PR
5. feat(traces): span pipeline #953 traces/05-pipeline
6. feat(traces): span export queue with retries #954 traces/06-export
7. feat(traces): per-span limits and exception stacktraces #955 traces/07-span-limits
8. feat(traces): before_span_send hook #956 traces/08-before-span-send
9. feat(traces): wire tracing into the client #957 traces/09-client-wiring

💚 How did you test it?

Unit tests in posthog/test/tracing/test_transport.py cover the request shape, every response class and Retry-After parsing.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Implemented with Claude Code (Claude Opus 5) against the traces spec, one commit per slice so each PR reviews on its own. Rebased onto main and opened as a stacked draft in a later Claude Code session (Claude Fable 5.1).

🤖 Generated with Claude Code

https://claude.ai/code/session_012o7CtHLfcypjmXL7g9ZGRC

[greptile-apps]

Prompt To Fix All With AI

### Issue 1
posthog/tracing/_transport.py:101-111
**Redirects can discard traces**

If a custom or self-hosted ingestion endpoint returns a 301, 302, or 303 redirect, `requests` follows it by default and may rewrite the POST as a GET. The final 2xx response is then reported as success even though the OTLP body was not ingested. Disable implicit redirects, or explicitly follow only bounded, same-origin 307/308 redirects while preserving the POST.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "feat(traces): span batch transport" | Re-trigger Greptile}

[github-actions]

posthog-python Compliance Report

Date: 2026-09-17 02:13:52 UTC
Duration: 256401ms

✅ All Tests Passed!

111/111 tests passed

---

Capture_V1 Tests

✅ 94/94 tests passed

View Details

Test	Status	Duration
Endpoint And Method.Targets V1 Endpoint	✅	517ms
Endpoint And Method.Does Not Use Legacy Endpoints	✅	511ms
Required Headers.Has Authorization Bearer Header	✅	510ms
Required Headers.Has Content Type Json	✅	510ms
Required Headers.Has Posthog Sdk Info Format	✅	510ms
Required Headers.Has Posthog Attempt Header	✅	511ms
Required Headers.Has Posthog Request Id	✅	510ms
Required Headers.Has Posthog Request Timestamp	✅	510ms
Required Headers.Has User Agent	✅	510ms
Body Format.Body Has Created At And Batch	✅	510ms
Body Format.No Api Key In Body	✅	511ms
Body Format.No Sent At In Body	✅	510ms
Event Format.Event Has Required Root Fields	✅	511ms
Event Format.Event Uuid Is Valid	✅	510ms
Event Format.Event Timestamp Is Rfc3339	✅	510ms
Event Format.Distinct Id Is String	✅	511ms
Event Format.Distinct Id At Root Not Properties	✅	510ms
Event Format.Custom Properties Preserved	✅	511ms
Event Format.Set Properties Preserved	✅	510ms
Event Format.Set Once Properties Preserved	✅	510ms
Event Format.Groups Properties Preserved	✅	511ms
Event Format.Sdk Generates Uuid If Not Provided	✅	509ms
Event Format.Event Has Required Root Fields Batch	✅	514ms
Event Format.Event Uuid Is Valid Batch	✅	514ms
Event Format.Event Timestamp Is Rfc3339 Batch	✅	514ms
Event Format.Distinct Id Is String Batch	✅	513ms
Event Format.Distinct Id At Root Not Properties Batch	✅	514ms
Event Format.Custom Properties Preserved Batch	✅	513ms
Event Format.Set Properties Preserved Batch	✅	514ms
Event Format.Set Once Properties Preserved Batch	✅	513ms
Event Format.Groups Properties Preserved Batch	✅	514ms
Event Format.Sdk Generates Uuid If Not Provided Batch	✅	514ms
Batch Behavior.Multiple Events In Single Batch	✅	517ms
Batch Behavior.Batch Envelope Smoke	✅	515ms
Batch Behavior.Flush With No Events Sends Nothing	✅	507ms
Batch Behavior.Flush At Triggers Batch	✅	1011ms
Batch Behavior.Created At Reflects Batch Creation Time	✅	511ms
Deduplication.Generates Unique Uuids	✅	517ms
Deduplication.Different Events Same Content Different Uuids	✅	512ms
Deduplication.Preserves Uuid On Retry	✅	6519ms
Deduplication.Preserves Timestamp On Retry	✅	6515ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	✅	6523ms
Deduplication.No Duplicate Events In Batch	✅	519ms
Header Behavior On Retry.Attempt Header Starts At One	✅	510ms
Header Behavior On Retry.Attempt Header Increments On Retry	✅	13518ms
Header Behavior On Retry.Request Id Preserved On Retry	✅	6519ms
Header Behavior On Retry.Different Requests Have Different Request Ids	✅	3020ms
Header Behavior On Retry.Request Timestamp Changes On Retry	✅	6519ms
Response Format Validation.Success Response Has Uuid Keyed Results	✅	511ms
Response Format Validation.Success Response Has Ok For Each Event	✅	514ms
Response Format Validation.Success No Retry After When All Ok	✅	512ms
Response Format Validation.Success Retry After Present When Retry Events	✅	1516ms
Response Format Validation.Success No Retry After When Drop Only	✅	512ms
Response Format Validation.Response Echoes Request Id	✅	510ms
Retry Behavior.Retries On 408	✅	6519ms
Retry Behavior.Retries On 500	✅	6516ms
Retry Behavior.Retries On 503	✅	8523ms
Retry Behavior.Retries On 504	✅	6519ms
Retry Behavior.Retryable Errors Have Retry After	✅	3517ms
Retry Behavior.Respects Retry After On Retryable Error	✅	11523ms
Retry Behavior.Does Not Retry On 400	✅	2514ms
Retry Behavior.Does Not Retry On 401	✅	2514ms
Retry Behavior.Does Not Retry On 402	✅	2513ms
Retry Behavior.Does Not Retry On 413	✅	2512ms
Retry Behavior.Does Not Retry On 415	✅	2513ms
Retry Behavior.Non Retryable Errors Have No Retry After	✅	2513ms
Retry Behavior.Implements Backoff	✅	22533ms
Retry Behavior.Max Retries Respected	✅	22536ms
Partial Batch Handling.Handles 200 Full Success	✅	2513ms
Partial Batch Handling.Handles 200 With All Ok	✅	3517ms
Partial Batch Handling.Does Not Retry Dropped Events	✅	3516ms
Partial Batch Handling.Does Not Retry Limited Events	✅	3516ms
Partial Batch Handling.Prunes Ok Events On Partial Retry	✅	6522ms
Partial Batch Handling.Prunes Dropped Events On Partial Retry	✅	6518ms
Partial Batch Handling.Retries Only Retry Events From Partial	✅	6523ms
Partial Batch Handling.Partial Retry Preserves Uuids	✅	6521ms
Partial Batch Handling.Partial Retry Attempt Header Increments	✅	6517ms
Partial Batch Handling.Partial Retry Request Id Preserved	✅	6520ms
Partial Batch Handling.Respects Retry After On Partial	✅	8518ms
Partial Batch Handling.Unknown Result Treated As Terminal	✅	3516ms
Partial Batch Handling.Mixed Ok Drop Limited No Retry	✅	3517ms
Compression.Sends Gzip Content Encoding	✅	511ms
Compression.No Content Encoding When Disabled	✅	510ms
Compression.Compressed Body Is Decompressible	✅	510ms
Error Handling.Does Not Retry On Unknown 4Xx	✅	2512ms
Event Options.Cookieless Mode Override	✅	511ms
Event Options.Disable Skew Correction Override	✅	510ms
Event Options.Process Person Profile Override	✅	510ms
Event Options.Product Tour Id Override	✅	510ms
Event Options.Unset Options Omitted	✅	510ms
Event Options.Options Override In Batch	✅	513ms
Geoip And Historical Migration.Geoip Disable Injected Into Properties	✅	510ms
Geoip And Historical Migration.Historical Migration Set In Body	✅	510ms
Geoip And Historical Migration.Historical Migration Absent By Default	✅	511ms

Feature_Flags Tests

✅ 17/17 tests passed

View Details

Test	Status	Duration
Request Payload.Request With Person Properties Device Id	✅	11ms
Request Payload.Flags Request Uses V2 Query Param	✅	9ms
Request Payload.Flags Request Hits Flags Path Not Decide	✅	8ms
Request Payload.Flags Request Omits Authorization Header	✅	10ms
Request Payload.Token In Flags Body Matches Init	✅	9ms
Request Payload.Groups Round Trip	✅	9ms
Request Payload.Groups Default To Empty Object	✅	9ms
Request Payload.Disable Geoip False Propagates As Geoip Disable False	✅	9ms
Request Payload.Disable Geoip Omitted Defaults To False	✅	9ms
Request Payload.Flag Keys To Evaluate Contains Only Requested Key	✅	9ms
Request Lifecycle.No Flags Request On Init Alone	✅	4ms
Request Lifecycle.No Flags Request On Normal Capture	✅	509ms
Request Lifecycle.Two Flag Calls Produce Two Remote Requests	✅	14ms
Request Lifecycle.Mock Response Value Is Returned To Caller	✅	9ms
Retry Behavior.Retries Flags On 502	✅	312ms
Retry Behavior.Retries Flags On 504	✅	313ms
Side Effect Events.Get Feature Flag Captures Feature Flag Called Event	✅	512ms

[greptile-apps]

_{Reviews (2): Last reviewed commit: "feat(traces): span batch transport" | Re-trigger Greptile}

[dustinbyrne]

One transport issue to address before the public tracing wiring:

At posthog/tracing/_transport.py:101–110, this POST downloads the entire response body even though classification uses only status and headers. Requests' timeout bounds read inactivity, not total response duration. A proxy returning 503 headers followed by an unfinished body with periodic chunks can keep this call open indefinitely instead of returning retry-later. The intended exporter holds its single-flight slot across the call.

Please classify a streamed response and reliably close it without consuming the unused body. That fixes this body-related hang; it does not by itself prove a whole-request deadline, particularly across redirects.

Regression sketch (not executed): use a local server returning 503 with a chunked body that sends every 10 ms without finishing; use a 0.5-second client timeout and assert the transport returns retry-later within two seconds. A completed 200 response is the negative control. Release the server loop during cleanup.

This is a private foundation issue, not a currently shipped Client tracing regression.

AI-assisted review with independent validation of source, pinned Requests/urllib3 implementations and existing CI; no new tests were run.

[turnipdabeets]

Good catch, fixed in 12bc88f. We now read only the status and headers, then close the response without reading the body. Added a test with a local server that returns 503 and keeps sending chunks forever. It hung before and now returns retry-later in under two seconds.

[dustinbyrne]

Thanks, this addresses my transport finding. I checked the streamed response, close in finally, and the new dripping-body regression test in 12bc88f. Current CI is green. Approving.

AI-assisted source and existing-CI review; I did not run new tests locally.

[jzhu13]

Reviewed against traces/03-span-handles. Tests pass at the head, and the outcome classification is sound: fatal drops, too-large halves to one then drops, retry-later is capped by #954's budget, so nothing can loop forever on a bad batch. The server-side route, bearer auth, and gzip handling in capture-logs match. One item I would fix before merge.

Blocking

1. posthog/tracing/_transport.py:101 stream=True plus response.close() without draining tears down the pooled connection after every batch. Reproduced: five traces POSTs to a keep-alive local server opened five TCP connections and the server logged a ConnectionResetError on each; five plain _get_session().post(...).content calls used one. Every flush pays a fresh TCP+TLS handshake to the ingestion host, and the 4xx log.error can never include the server's {"error": ...} body, so a mistyped key surfaces as bare HTTP 401 every interval. The drip protection is worth keeping. Suggest draining when Content-Length is present and small (capture-logs always sets it on its Json(...) responses) and closing unread only when it is absent or large.

Non-blocking

2. posthog/tracing/_transport.py:33 SendOutcome.kind is a free-form str. #954's _apply_outcome_locked ends in a fallthrough that deletes the batch, so a typo in any future call site silently drops spans instead of failing typecheck. Literal["ok", "retry-later", "too-large", "fatal"] closes that.
3. posthog/tracing/_transport.py:49 parse_retry_after is the third Retry-After parser in the SDK, after request._process_response and capture_v1._parse_retry_after, and the most correct of the three. It belongs in posthog/request.py with capture_v1 pointed at it.
4. Nits: the try/except around parse_retry_after(response.headers.get(...)) is dead code propped up by a mock-only test, since the parser returns None on every malformed input; test_transport.py:155 asserts a 2099 HTTP-date against the real clock; gzip.compress at level 9 measured 2x the CPU of level 6 for about 1% more bytes.

Reviewed with Claude Code (Claude Fable 5.1). Behaviors above were reproduced against this branch head.

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10

[turnipdabeets]

Thanks. Fixed in be59068:

• 1: a body up to 64 KiB is read so the pooled connection survives (test counts one connection over five posts). A fatal status now logs the server's error body.
• 2: Literal for the outcome kind.
• 4: dead Retry-After guard and its mock-only test removed, HTTP-date test derives its date from now, gzip level 6.
• 3: declining for this stack since it touches capture_v1. Happy to do it as a follow-up.

[turnipdabeets]

Follow-up: nothing further changed here since be59068; the stack below it was rebased. Ready for another look.