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

Improve error handling #965

Closed
tedsuo opened this issue Sep 17, 2020 · 9 comments
Closed

Improve error handling #965

tedsuo opened this issue Sep 17, 2020 · 9 comments
Assignees
Labels
area:api Cross language API specification issue area:error-reporting Related to error reporting priority:p1 Highest priority level release:required-for-ga Must be resolved before GA release, or nice to have before GA spec:trace Related to the specification/trace directory

Comments

@tedsuo
Copy link
Contributor

tedsuo commented Sep 17, 2020

What are you trying to achieve?
Improved error handling, based on OTEP 136.

  • Reduce the number of Status Codes.
  • Add Status Source.
  • Indicate which semantic conventions generate errors.

Additional context.
OTEP PR: open-telemetry/oteps#136

This issue supersedes #706.

@tedsuo tedsuo added the spec:trace Related to the specification/trace directory label Sep 17, 2020
@Oberon00 Oberon00 added area:api Cross language API specification issue area:error-reporting Related to error reporting release:required-for-ga Must be resolved before GA release, or nice to have before GA labels Sep 17, 2020
@arminru arminru added the priority:p1 Highest priority level label Sep 17, 2020
@arminru
Copy link
Member

arminru commented Sep 17, 2020

Classified as p1 since it supersedes the p1 #706 and is quite pervasive.

Indicate which semantic conventions generate errors.

Should we split this into a separate (p3 or after-ga) issue?

@tedsuo
Copy link
Contributor Author

tedsuo commented Sep 17, 2020

@arminru I will include the HTTP status codes as part of this issue. I agree a separate issue for the rest of the semantics.

@carlosalberto
Copy link
Contributor

carlosalberto commented Sep 25, 2020

@tedsuo @arminru my impression is that we should close this issue, as the core has been implemented/updated - the remaining semantic conventions to be updated can be labeled as "good do have for GA", as they technically won't break the API ;)

EDIT: I just saw that indeed we plan to create a new issue for the follow up ;)

I agree a separate issue for the rest of the semantics.

@carlosalberto
Copy link
Contributor

Closed via #966

@arminru
Copy link
Member

arminru commented Sep 25, 2020

Follow-up for the semantic conventions: #1003

@arminru
Copy link
Member

arminru commented Oct 13, 2020

@open-telemetry/technical-committee @tedsuo

I just noticed this issue was closed without adding Status Source (instrumentation | user), which was part of the OTEP and also the issue description ("Add Status Source.") to the spec in #966.

Was this missed or intentionally dropped from GA?

@arminru arminru reopened this Oct 13, 2020
@carlosalberto
Copy link
Contributor

carlosalberto commented Oct 14, 2020

@arminru IIRC StatusSource was removed based on public feedback. @tedsuo May remember the details ;)

(And to be clear: the OTEPs can always still change when hitting the Specification. A sampling and a context-prop OTEP come to mind).

@Oberon00
Copy link
Member

I think the comment that successfully argued for the removal is this: #966 (comment)

As pointed also in the otep. I am worried that we add things right before GA that we will regret and have to maintain for years.

I strongly suggest to not add the source yet, adding it later is backwards compatible.

@arminru
Copy link
Member

arminru commented Oct 14, 2020

I added #1092 (labeled as after-ga) to keep track of this part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:api Cross language API specification issue area:error-reporting Related to error reporting priority:p1 Highest priority level release:required-for-ga Must be resolved before GA release, or nice to have before GA spec:trace Related to the specification/trace directory
Projects
None yet
Development

No branches or pull requests

4 participants