Skip to content

Conversation

@adamw
Copy link
Member

@adamw adamw commented Jan 16, 2026

Set the span kind to CLIENT for HTTP client requests in OpenTelemetryTracingBackend to match the behavior of other tracing backends (otel4s-tracing-backend and opentelemetry-tracing-zio-backend).

Fixes #2762

Generated with Claude Code

Set the span kind to CLIENT for HTTP client requests in OpenTelemetryTracingBackend to match the behavior of other tracing backends (otel4s-tracing-backend and opentelemetry-tracing-zio-backend).

Fixes #2762

Co-authored-by: Adam Warski <adamw@users.noreply.github.com>
@claude
Copy link

claude bot commented Jan 16, 2026

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

@adamw
Copy link
Member Author

adamw commented Jan 16, 2026

@claude is it possible to extend any of the existing tests so that they verify that the span kind if set correctly?

@claude
Copy link

claude bot commented Jan 16, 2026

Claude finished @adamw's task in 1m 21s —— View job


Investigation complete ✓

  • Read repository guidelines (CLAUDE.md)
  • Examine the changed file and understand the fix
  • Find existing tests for OpenTelemetryTracingBackend
  • Check tests in other tracing backends (otel4s, zio) for span kind verification
  • Verify SpanData API for accessing span kind
  • Provide recommendations

Answer

Yes, the existing tests in OpenTelemetryTracingBackendTest.scala can be extended to verify the span kind. The SpanData objects returned by testExporter.getFinishedSpanItems() have a getKind() method that returns the SpanKind enum value.

Recommended changes

Both existing test cases ("capture successful spans" and "capture spans which end in an exception") can be enhanced by adding a single assertion. Here's what to add:

In the "capture successful spans" test (after line 35):

span.getKind() shouldBe io.opentelemetry.api.trace.SpanKind.CLIENT

In the "capture spans which end in an exception" test (after line 60):

span.getKind() shouldBe io.opentelemetry.api.trace.SpanKind.CLIENT

Full context

The tests already retrieve the span object:

val span = spanItems.head

And perform various assertions on it (name, attributes, etc.). Adding the span kind assertion would be a natural extension that verifies the fix in PR #2765.

Note: Currently, none of the other tracing backend tests (otel4s-tracing-backend or opentelemetry-tracing-zio-backend) verify span kind either, so this would establish a new testing pattern that could potentially be adopted by those backends as well.

Would you like me to implement these test enhancements?

--- | Branch: claude/issue-2762-20260116-1015

@adamw
Copy link
Member Author

adamw commented Jan 16, 2026

@claude yes please, extend all tests

@claude
Copy link

claude bot commented Jan 16, 2026

Claude finished @adamw's task in 1m 30s —— View job


Tests extended ✓

  • Read repository guidelines (CLAUDE.md)
  • Locate and read the test file
  • Add span kind assertions to both test cases
  • Commit and push changes

Changes made

Added span kind assertions to both test cases in OpenTelemetryTracingBackendTest.scala:

  1. "capture successful spans" test (line 36): Added assertion to verify SpanKind.CLIENT
  2. "capture spans which end in an exception" test (line 62): Added assertion to verify SpanKind.CLIENT

Both tests now verify that the span kind is correctly set to CLIENT for HTTP client requests, ensuring the fix in this PR is properly tested.

The CI will run the tests to verify the changes work correctly.

--- | Branch: claude/issue-2762-20260116-1015 |

Co-authored-by: Adam Warski <adamw@users.noreply.github.com>
@adamw adamw merged commit 79472c7 into master Jan 16, 2026
20 checks passed
@adamw adamw deleted the claude/issue-2762-20260116-1015 branch January 16, 2026 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OpenTelemetry tracing does not set the span kind

2 participants