Issue:
While polling an external API endpoint, the baggage header grows each iteration of the poll with sentry-trace_id, sentry-environment, and sentry-release repeating in each loop. After a while (if the poll does not resolve) the header eventually grows so big it errors with 431 "Request header fields too large" error on HTTP fetch.

Similar Issues

• Python CeleryIntegration accumulates baggage header data on retry #2916
  • Similar issue, but our case is not using celery
• Sentry Integration Causing '431 Request Header Fields Too Large' Error with FastAPI and Azure API Management #3526
  • Similar issue, but our case is not using Azure API Management
  • Failed to recognize that the reason they were too large was due to the headers being added multiple times.
• Duplicated values in Sentry Baggage header cause eventual 431 "Request header fields too large" error on HTTP fetch sentry-javascript#12350
  • Same issue, but this example is from javascript and our case is in python (using sentry-python)

SDK Version:
sentry-sdk==2.13.0

Example:

from httpx import AsyncClient


while is_still_processing:
  async with AsyncClient() as http_client:
      http_request = http_client.build_request(
          method="GET",
          url=MY_URL,
          content=MY_BODY,
          headers={"content-type":  "application/json"}
      )
  
    http_response = await AsyncClient.send(request=http_request)
    http_response.raise_for_status()

    is_still_processing = is_successful_response(http_response)
    if not is_still_processing():
        return http_response.content
    await asyncio.sleep(0.5)

In the above example, the baggage header in the request grows with each iteration.

Note
The trace_propagation_targets is available to bypass the issue, but it doesn't fix the root cause.

The javascript lib issue was fixed by using .set() instead of .append(), so the Python lib might be resolved in a similar manner?