Skip to content

fix(otel): sanitize OTLP endpoint URL resolution#13791

Merged
vincentkoc merged 3 commits intoopenclaw:mainfrom
vincentkoc:vincentkoc-code/fix-otel-endpoint-url-sanitize-final4
Feb 19, 2026
Merged

fix(otel): sanitize OTLP endpoint URL resolution#13791
vincentkoc merged 3 commits intoopenclaw:mainfrom
vincentkoc:vincentkoc-code/fix-otel-endpoint-url-sanitize-final4

Conversation

@vincentkoc
Copy link
Copy Markdown
Member

@vincentkoc vincentkoc commented Feb 11, 2026

Summary

Sanitizes OTLP endpoint resolution so non-signal endpoints that contain internal /v1/ segments still append the correct signal path. Keeps already signal-qualified endpoints unchanged. lobster-biscuit

Motivation

This prevents silent cloud export misrouting for valid backends like Opik that use /api/v1/... in their base URL. Closes #13783

Changes

Related

Greptile Overview

Greptile Summary

Fixes OTLP endpoint URL resolution to prevent misrouting for backends that contain internal /v1/ segments (like Opik's /api/v1/...). The change replaces simple substring matching with strict signal-path pattern matching (/v1/traces, /v1/metrics, /v1/logs) that strips query parameters and fragments before testing, ensuring already signal-qualified endpoints remain unchanged while non-signal endpoints get the correct signal path appended.

Key improvements:

  • Strips query params and fragments before regex matching to avoid false negatives
  • Uses strict end-of-pathname matching for signal paths instead of broad /v1/ substring detection
  • Preserves original endpoint (including query params) when already signal-qualified
  • Adds comprehensive test coverage for both internal-/v1/ base endpoints and signal-qualified endpoints with query parameters

The implementation correctly addresses the regression mentioned in the previous thread by extracting the pathname portion for testing while preserving the full URL for the return value.

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk
  • The change is focused, well-tested, and correctly addresses the reported issue. The previous thread's concern about query parameters has been properly resolved through the endpoint.split(/[?#]/, 1)[0] approach. The test suite includes three relevant test cases covering the key scenarios (non-signal /v1/ segments, already signal-qualified endpoints, and signal-qualified endpoints with query params). The logic is straightforward and the regex pattern is precise.
  • No files require special attention

@openclaw-barnacle openclaw-barnacle Bot added the extensions: diagnostics-otel Extension: diagnostics-otel label Feb 11, 2026
@vincentkoc vincentkoc marked this pull request as ready for review February 11, 2026 02:00
Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps Bot left a comment

Choose a reason for hiding this comment

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

2 files reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

Comment thread extensions/diagnostics-otel/src/service.ts Outdated
@vincentkoc
Copy link
Copy Markdown
Member Author

@greptileai i patched the regex as you requested and tests passing, PR is ready to merge so can you update the score.

Copy link
Copy Markdown
Contributor

@0xRaini 0xRaini left a comment

Choose a reason for hiding this comment

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

Nice fix! The old endpoint.includes("/v1/") check was too broad — it would incorrectly skip appending the signal path for URLs like https://example.com/opik/api/v1/private/otel where /v1/ is part of the provider's API path, not the OTLP signal path.

What I liked:

  • The regex /\/v1\/(?:traces|metrics|logs)$/ is precise — only matches when the path ends with a known OTLP signal segment
  • Stripping query/fragment before matching is important for correctness
  • Excellent test coverage with three distinct scenarios (non-signal /v1, already-qualified, with query params)

suggestion: The split(/[?#]/, 1)[0] ?? endpoint fallback is fine, but split with limit 1 always returns at least one element, so the ?? endpoint is technically unreachable. Not a problem, just a nit — it's good defensive code.

question: Should the regex also handle uppercase signal names (e.g., /v1/Traces)? I've seen some OTLP collectors that aren't strict about case. Probably fine as-is since the official spec uses lowercase, but worth considering.

LGTM! 🎯

@vincentkoc
Copy link
Copy Markdown
Member Author

question: Should the regex also handle uppercase signal names (e.g., /v1/Traces)? I've seen some OTLP collectors that aren't strict about case. Probably fine as-is since the official spec uses lowercase, but worth considering.

@0xRaini added the case-insenstive check, good catch!

@vincentkoc vincentkoc merged commit 88f6989 into openclaw:main Feb 19, 2026
23 checks passed
@vincentkoc vincentkoc deleted the vincentkoc-code/fix-otel-endpoint-url-sanitize-final4 branch February 19, 2026 10:03
mmyyfirstb pushed a commit to mmyyfirstb/openclaw that referenced this pull request Feb 21, 2026
* fix(otel): sanitize OTLP endpoint signal URL resolution

* fix(otel): preserve signal URLs with query params

* fix(otel): accept case-insensitive signal paths
zooqueen pushed a commit to hanzoai/bot that referenced this pull request Mar 6, 2026
* fix(otel): sanitize OTLP endpoint signal URL resolution

* fix(otel): preserve signal URLs with query params

* fix(otel): accept case-insensitive signal paths
lovewanwan pushed a commit to lovewanwan/openclaw that referenced this pull request Apr 28, 2026
* fix(otel): sanitize OTLP endpoint signal URL resolution

* fix(otel): preserve signal URLs with query params

* fix(otel): accept case-insensitive signal paths
ogt-redknie pushed a commit to ogt-redknie/OPENX that referenced this pull request May 2, 2026
* fix(otel): sanitize OTLP endpoint signal URL resolution

* fix(otel): preserve signal URLs with query params

* fix(otel): accept case-insensitive signal paths
github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request May 9, 2026
* fix(otel): sanitize OTLP endpoint signal URL resolution

* fix(otel): preserve signal URLs with query params

* fix(otel): accept case-insensitive signal paths
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

extensions: diagnostics-otel Extension: diagnostics-otel

Projects

None yet

Development

Successfully merging this pull request may close these issues.

diagnostics-otel: sanitize OTLP endpoint URL resolution (avoid false /v1 detection)

2 participants