Summary

• Problem: The diagnostics-otel extension ships with every install but has never actually worked. Three bugs stack on top of each other to prevent any telemetry from reaching a collector.
• Why it matters: Users configuring OTel get no errors but also no data. Multiple open issues (Plugin's onDiagnosticEvent() and gateway's emitDiagnosticEvent() use different module instances due to jiti isolation. Events never reach the plugin. Needs core fix (globalThis or context injection). openclaw/openclaw#5190, diagnostics-otel loads but does not emit OTLP traffic to configured endpoint openclaw/openclaw#18794, diagnostics-otel: sanitize OTLP endpoint URL resolution (avoid false /v1 detection) openclaw/openclaw#13783) with community confirmations.
• What changed: (1) Diagnostic event bus and log transport registry now use globalThis[Symbol.for()] singletons so plugin bundles share state with core. (2) resolveOtelUrl() uses endsWith against OTLP signal suffixes instead of includes("/v1/").
• What did NOT change: No new dependencies, no config schema changes, no new diagnostic event types. The OTel plugin's metrics/spans/logs handling is untouched.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Plugin's onDiagnosticEvent() and gateway's emitDiagnosticEvent() use different module instances due to jiti isolation. Events never reach the plugin. Needs core fix (globalThis or context injection). openclaw/openclaw#5190
• Closes diagnostics-otel loads but does not emit OTLP traffic to configured endpoint openclaw/openclaw#18794
• Closes diagnostics-otel: sanitize OTLP endpoint URL resolution (avoid false /v1 detection) openclaw/openclaw#13783
• Related fix: share diagnostic event listeners across module bundles openclaw/openclaw#11168, fix(diagnostics-otel): share listeners/transports across module bundles openclaw/openclaw#16865, fix(logging): use Symbol.for for externalTransports to survive jiti module isolation openclaw/openclaw#12475, fix(otel): complete diagnostics-otel OpenTelemetry v2 API migration openclaw/openclaw#12897, fix(otel): sanitize OTLP endpoint URL resolution openclaw/openclaw#13791, fix: share diagnostic event bus across bundle chunks via globalThis openclaw/openclaw#18894

User-visible / Behavior Changes

Users who configure diagnostics.otel.enabled: true with an OTLP endpoint will now actually receive traces, metrics, and logs in their collector. Previously this configuration was silently non-functional.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No (the OTel plugin already makes OTLP calls when enabled -- they just never fired due to the event bus bug)
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS (Darwin arm64)
• Runtime: Node v25.6.1
• Integration: diagnostics-otel extension + Jaeger OTLP collector

Steps

1. Start Jaeger: docker run -d -p 127.0.0.1:4318:4318 -p 127.0.0.1:16686:16686 jaegertracing/all-in-one:latest
2. Configure OpenClaw with diagnostics.enabled: true, diagnostics.otel.enabled: true, diagnostics.otel.endpoint: http://127.0.0.1:4318
3. Emit diagnostic events (via gateway activity or test script)

Expected

Traces appear in Jaeger at http://localhost:16686

Actual

Before fix: zero traces (confirmed via ss -tn, matching openclaw#18794 repro).
After fix: 3 traces with 3 spans appear in Jaeger.

Evidence

• Failing test/log before + passing after
• Trace/log snippets

Unit tests: 18/18 pass (5 new tests added covering the exact bug scenarios).

Integration test output:

OTel service started, emitting test events...
Events emitted. Waiting for OTel batch flush...
OTel service stopped.
SUCCESS: Found 3 trace(s) with 3 span(s) in Jaeger.

URL resolution test covers the openclaw#13783 case directly:

"appends signal path when endpoint contains /v1/ in a non-terminal position"
  https://api.example.com/api/v1/private/otel -> .../api/v1/private/otel/v1/traces

Human Verification (required)

• Verified scenarios: Event bus isolation fix confirmed with live Jaeger collector. URL resolution fix confirmed with Opik-style endpoint containing /v1/ in base path.
• Edge cases checked: Endpoint already ending in /v1/traces (no double-append), resetDiagnosticEventsForTest() correctly clears shared state, unsubscribe removes only the target listener.
• What I did not verify: gRPC protocol (intentionally unsupported), concurrent multi-process scenarios (Vitest workers are isolated).

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert this single commit. The globalThis singletons degrade gracefully -- if removed, behavior returns to the pre-fix state (events don't cross module boundaries, but nothing crashes).
• Files/config to restore: src/infra/diagnostic-events.ts, src/logging/logger.ts, extensions/diagnostics-otel/src/service.ts
• Known bad symptoms reviewers should watch for: If globalThis symbols collide with another library (extremely unlikely with openclaw. prefix), diagnostic events could leak to unintended listeners.

Risks and Mitigations

• Risk: globalThis shared state could cause test interference if tests in the same Vitest worker share the bus.
  • Mitigation: resetDiagnosticEventsForTest() already exists for this purpose and now clears the shared bus. Existing tests already call it in beforeEach. New test added to verify this works.

AI disclosure: This PR was developed with AI assistance (Claude). All changes were manually reviewed, understood, and verified with live integration testing against Jaeger.