fix: be compliant on retries and compression

[andehen]

Problem

The SDK was not compliant with the SDK harness tests on retries and compression.

Changes

• Add structured HTTP error handling and retryable status classification.
• Respect Retry-After header by using max(backoff, retry-after).
• Apply adapter config for retries and gzip compression.

Testing

• SDK compliance harness: passes (adapter-driven tests).

[github-actions]

posthog-go Compliance Report

Date: 2026-02-06 08:50:53 UTC
Duration: 105796ms

✅ All Tests Passed!

29/29 tests passed

---

Capture Tests

✅ 29/29 tests passed

View Details

Test	Status	Duration
Format Validation.Event Has Required Fields	✅	607ms
Format Validation.Event Has Uuid	✅	608ms
Format Validation.Event Has Lib Properties	✅	607ms
Format Validation.Distinct Id Is String	✅	608ms
Format Validation.Token Is Present	✅	607ms
Format Validation.Custom Properties Preserved	✅	607ms
Format Validation.Event Has Timestamp	✅	607ms
Retry Behavior.Retries On 503	✅	5612ms
Retry Behavior.Does Not Retry On 400	✅	2610ms
Retry Behavior.Does Not Retry On 401	✅	2610ms
Retry Behavior.Respects Retry After Header	✅	5613ms
Retry Behavior.Implements Backoff	✅	15622ms
Retry Behavior.Retries On 500	✅	5614ms
Retry Behavior.Retries On 502	✅	5613ms
Retry Behavior.Retries On 504	✅	5613ms
Retry Behavior.Max Retries Respected	✅	15617ms
Deduplication.Generates Unique Uuids	✅	618ms
Deduplication.Preserves Uuid On Retry	✅	5612ms
Deduplication.Preserves Uuid And Timestamp On Retry	✅	10619ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	✅	5613ms
Deduplication.No Duplicate Events In Batch	✅	611ms
Deduplication.Different Events Have Different Uuids	✅	610ms
Compression.Sends Gzip When Enabled	✅	605ms
Batch Format.Uses Proper Batch Structure	✅	608ms
Batch Format.Flush With No Events Sends Nothing	✅	605ms
Batch Format.Multiple Events Batched Together	✅	610ms
Error Handling.Does Not Retry On 403	✅	2610ms
Error Handling.Does Not Retry On 413	✅	2610ms
Error Handling.Retries On 408	✅	5612ms

[rodrigoi]

I think that we may need a max retry count in parseRetryAfter. Otherwise, nitpicks here and there.

[andehen]

I think that we may need a max retry count in parseRetryAfter

That function is only responsible for parsing the server hint. We already have maxAttempts that controls how many times we'll wait.