Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[tracing] Match client and server spans with OpenTelemetry specification #8541

Merged
merged 4 commits into from Jul 17, 2020

Conversation

pujagani
Copy link
Contributor

Description

The changes are related to issue #6703. Improvises existing HTTP span error handling.

Motivation and Context

Current implementation has SpanWrapperHTTPHandler to generate spans for any request received by the server and TracedHTTPClient to generate spans for a client request. The changes help adhere to the OpenTelemetry specification to ensure consistent HTTP spans. The HTTP error code mapping with span status adheres to OpenTelemetry specification and W3C Webdriver Error Codes.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • I have read the contributing document.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

res.getTargetHost();
span.setAttribute("http.status_code", statusCode);

switch (statusCode / 100) {
Copy link
Member

Choose a reason for hiding this comment

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

This would be better as just status codes rather divided

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I understand your point. The division is so we can match the error code to a family of error codes rather than a particular error code. I did consider a cleaner way of doing using native java package but we don't have that dependency in the workspace. I think I can leverage existing Netty server response to make the code readable rather that using if-else.

@AutomatedTester AutomatedTester merged commit a4e7fe0 into SeleniumHQ:trunk Jul 17, 2020
@AutomatedTester
Copy link
Member

This is much better without the magic numbers!

titusfortner pushed a commit to titusfortner/selenium that referenced this pull request Aug 13, 2020
…ion (SeleniumHQ#8541)



Co-authored-by: David Burns <david.burns@theautomatedtester.co.uk>
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.

None yet

2 participants