Improve native trace exporter#5817
Conversation
|
|
👋 Hey @lloeki, please fill "Change log entry" section in the pull request description. If changes need to be present in CHANGELOG.md you can state it this way **Change log entry**
Yes. A brief summary to be placed into the CHANGELOG.md(possible answers Yes/Yep/Yeah) Or you can opt out like that **Change log entry**
None.(possible answers No/Nope/None) Visited at: 2026-05-27 13:55:53 UTC |
Switch from `ddog_TraceExporterError *` to `ddog_MaybeError` for all tracer construction functions (`span_new`, `set_meta`, `set_metric`, `trace_chunks_new`, `begin_chunk`, `push_span`). Use the existing `read_ddogerr_string_and_drop` helper via a new `check_maybe_error` inline function. `send_trace_chunks` retains `ddog_TraceExporterError` because callers need the error code for HTTP response classification.
Replace the separate `*const uint8_t` return + `out_len` out-parameter with a single `ddog_ByteSlice` struct, matching the updated libdatadog FFI signature.
d5fa393 to
bd141e3
Compare
b49856e to
2b00aa3
Compare
The tracer construction functions return `ddog_TraceExporterError *` again, matching the libdatadog FFI. Restore `check_exporter_error` usage at the call sites and drop the `ddog_MaybeError`-based handling. This reverts the consumer-side `ddog_MaybeError` adaptation: the structured `ExporterError` type with error codes is retained upstream instead.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bf8ee694ff
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ddog_ByteSlice body = | ||
| ddog_trace_exporter_response_get_body(args.response); |
There was a problem hiding this comment.
Keep get_body call compatible with libdatadog 33
With the current datadog.gemspec dependency on libdatadog ~> 33.0.0.1.0, the vendored data-pipeline.h still declares ddog_trace_exporter_response_get_body(const ddog_TraceExporterResponse *, uintptr_t *out_len) returning const uint8_t *; it does not return ddog_ByteSlice or accept a single argument. Any install that builds ext/libdatadog_api against the declared dependency will fail to compile here, so this needs either the old two-argument call or a matching libdatadog dependency/header update.
Useful? React with 👍 / 👎.
What does this PR do?
Motivation:
Change log entry
Additional Notes:
How to test the change?