Event dropped by rate limiter warning in Sentry SDK

When a Sentry server replies with HTTP 429, the client SDK emits an "Event dropped by rate limiter" warning. The response usually contains a Retry-After header that indicates how long the client should pause before sending further events. Some language bindings (e.g., JavaScript) parse and respect this header, while others (e.g., Python in older releases) ignore it and instead apply a fixed exponential back‑off strategy. This divergence can cause unpredictable event loss during traffic spikes and raises questions about the intended, documented behavior.

The goal of this inquiry is to clarify how each SDK handles the Retry-After header and why the implementation differs across bindings.

Key unresolved questions:

• Does the current Sentry SDK for each language parse and honor the Retry-After header when a 429 response is received?
• If some SDKs ignore the header, what is the rationale behind that design choice?
• How can we standardize the retry strategy across all SDKs to reduce event loss during rate limiting?