Skip to content

Include all trace export payloads #1349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
Closed

Conversation

mshsheikh
Copy link
Contributor

@mshsheikh mshsheikh commented Aug 2, 2025

  1. Adds default timeout to httpx.Timeout for full compatibility with older versions
  2. Prevents client initialization errors in Python 3.9 and earlier
  3. Includes all item.export() results in the export payload, even falsy ones
  4. Improves trace completeness and data consistency during export
  5. Verified against test suite for Python 3.9 and newer compatibility

* Correct the `httpx.Timeout` call to use separate `connect` and `read` timeouts
* Prevent client initialization errors by using a valid timeout signature
* Remove the `if item.export()` filter so no exported data is dropped
* Ensure empty or falsy `export()` results are still sent to the backend
* Improve reliability of trace exports without changing existing APIs
* Adds a default timeout to the `httpx.Timeout` config to avoid runtime errors during client initialization (required by older HTTPX versions).
* Ensures that all items from `item.export()` are included in the payload, even if empty or falsy, for complete trace logging.
* Fix maintains backward compatibility and passes all Python 3.9+ tests.
@mshsheikh mshsheikh changed the title Fix HTTPX timeout and include all export items Fix HTTPX timeout config and include all trace export payloads Aug 2, 2025
Copy link
Member

@seratch seratch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the second change is really relevant, we may be interested in it. That said, we need more information on it.

@@ -96,7 +97,8 @@ def export(self, items: list[Trace | Span[Any]]) -> None:
logger.warning("OPENAI_API_KEY is not set, skipping trace export")
return

data = [item.export() for item in items if item.export()]
# include all export() results, even if they’re empty/falsy
data = [item.export() for item in items]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate more on this? If there is a certain situation to resolve, we're happy to adjust this logic, but we aren't aware of anything.

@@ -60,7 +60,8 @@ def __init__(
self.max_delay = max_delay

# Keep a client open for connection pooling across multiple export calls
self._client = httpx.Client(timeout=httpx.Timeout(timeout=60, connect=5.0))
# use separate connect/read timeouts
self._client = httpx.Client(timeout=httpx.Timeout(60.0, connect=5.0))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't change anything on the actual behavior, so we don't need this change.

@seratch seratch changed the title Fix HTTPX timeout config and include all trace export payloads Include all trace export payloads Aug 2, 2025
@mshsheikh
Copy link
Contributor Author

If the second change is really relevant, we may be interested in it. That said, we need more information on it.

We made NoOpSpan.export() and NoOpTrace.export() return { } on purpose; that { } tells you “this span/trace ran but there was nothing extra to send.”
If you drop every falsy result, you’ll never see those no-ops and your dashboards end up missing real events.

Bottom line: the core tracer should hand over every export result, even if it’s empty. If a backend or custom exporter wants to drop empties, they can do that themselves where it’s obvious and logged, not buried in the heart of the tracing code.

@mshsheikh mshsheikh requested a review from seratch August 2, 2025 01:11
@seratch
Copy link
Member

seratch commented Aug 2, 2025

Thanks for your reply, but changing the behavior could break existing integrations' behaviors, plus I don't see the necessity to send empty data to tracing data platform as it does not provide meaningful information. Thanks again for sending this but let me close it now.

@seratch seratch closed this Aug 2, 2025
@mshsheikh mshsheikh deleted the patch-28 branch August 2, 2025 12:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants