update OLTP doc - #555
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3a92b3d503
ℹ️ 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".
|
|
||
| `OTLPExporter` doesn't care whether the URL is a backend or your own proxy — it POSTs the same OTLP/HTTP JSON either way, so no custom `TraceExporter` is needed. What your endpoint receives and how it should behave: | ||
|
|
||
| - **`POST <your-url>/v1/traces`**, `Content-Type: application/json`, body is an OTLP `ExportTraceServiceRequest`. It must return **2xx** or the batch is dropped (there is no retry — see [Error handling](#error-handling)). |
There was a problem hiding this comment.
The exporter never appends /v1/traces; URLSessionPoster.post builds URLRequest(url: endpoint) from exactly the URL passed to OTLPExporter. Since the example above already configures https://telemetry.example.com/v1/traces, documenting the receiver as POST <your-url>/v1/traces can lead gateway implementations or configs to add the suffix twice, causing requests to hit the wrong route. Please describe this as a POST to the configured endpoint, e.g. /v1/traces when that is the endpoint you pass.
Useful? React with 👍 / 👎.
|
@claude analyze the Codex Review and give me your assessment. |
|
Claude finished @cornelcroi's task in 53s —— View job Assessment of Codex Review
Codex's finding is correct — this is a real, if minor, doc bug. I verified against the implementation:
So the exporter POSTs to exactly whatever The problem in the new doc section (
That's misleading: if a reader configures a different Suggested fix: rephrase line 142 to describe the request as hitting the configured endpoint directly, e.g.:
This keeps the concrete I did not make this change since the request was only for an assessment — let me know if you'd like me to implement the fix. |
|
@claude make a pr with the fix |
|
Claude finished @cornelcroi's task in 33s —— View job Fix applied ✅
Implemented the fix from my earlier assessment. Changed line 142 from:
to:
This makes clear the exporter POSTs to exactly whatever Pushed as commit |
Codex review flagged that OTLPExporter never appends /v1/traces to the endpoint — it POSTs to exactly the URL passed in. Describing the gateway contract as "POST <your-url>/v1/traces" could lead readers to double-append the suffix on their gateway route. Co-authored-by: Corneliu Croitoru <cornelcroi@users.noreply.github.com>
1 participant
Issue Link (REQUIRED)
Fixes #
Summary
Changes
User experience
Checklist
If your change doesn't seem to apply, please leave them unchecked.
Is this a breaking change?
RFC issue number:
Checklist:
Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.