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

Add exception.escaped attribute. #784

Merged

Conversation

Oberon00
Copy link
Member

@Oberon00 Oberon00 commented Aug 11, 2020

Originally discussed in #697 (comment).

This was split from and requires #761. See also discussion there.

Depends on #814 ✔️ for the RecordException change. The API addition was removed on @bogdandrutu's request, see #784 (comment) (and earlier #784 (comment))

Changes

  • Add exception.escaped attribute to mark definitely escaped exceptions.

@Oberon00 Oberon00 added area:api Cross language API specification issue area:semantic-conventions Related to semantic conventions area:error-reporting Related to error reporting spec:trace Related to the specification/trace directory release:after-ga Not required before GA release, and not going to work on before GA labels Aug 11, 2020
@Oberon00 Oberon00 requested a review from a team as a code owner August 11, 2020 16:49
@Oberon00 Oberon00 requested a review from a team August 11, 2020 16:49
@Oberon00 Oberon00 requested a review from a team as a code owner August 11, 2020 16:49
Copy link
Member

@arminru arminru left a comment

Choose a reason for hiding this comment

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

Once #761 is merged you should also update the code sample there to properly set escaped=true.

@Oberon00 Oberon00 requested review from mwear and iNikem August 12, 2020 13:45
@bogdandrutu bogdandrutu self-assigned this Aug 12, 2020
Comment on lines 519 to 520
- `RecordException(exception: Exception, escaped: boolean? = null)`
- `RecordException(type: String, message: String, stacktrace: String, escaped: boolean?)`
Copy link
Member

Choose a reason for hiding this comment

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

I would like to think this way:
"Is this information so important that deserves being a first class concept in our API"?

Also are there any other fields that are optional? If we add the optional concept to this API does it apply to other fields like stacktrace?

Copy link
Member Author

@Oberon00 Oberon00 Aug 17, 2020

Choose a reason for hiding this comment

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

"Is this information so important that deserves being a first class concept in our API"?

I think so (given that we have already decided that exceptions are important enough). More importantly, there is no way to customize the event created by recordException, so you have to add API support for it to make it practically usable at all.

Also are there any other fields that are optional? If we add the optional concept to this API does it apply to other fields like stacktrace?

Interesting thought, especially since retrieving (and exporting) the stacktrace might be expensive. I created #814 to track this.

Copy link
Member Author

@Oberon00 Oberon00 Aug 17, 2020

Choose a reason for hiding this comment

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

If we add the optional concept to this API

Since this is marked after-ga, I had to make it optional to avoid breakage. But now it seems this PR already has enough approvals to get it merged for GA. I would be fine with making these required parameters (maybe in a follow-up to not invalidate approvals) thus avoiding the "optional concept". WDYT?

Or way your question less about the default = null but more about the ? type that allows null? I think allowing to not set the attribute is required here since you don't know in all situations.

Copy link
Contributor

Choose a reason for hiding this comment

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

I personally prefer it as an optional parameter (it would also mean merging this PR sooner, as a further conversation of making it required would happen in a follow up).

@bogdandrutu any objection to PR this merge? Although it indeed has enough approvals, you raised an issue here ;)

Copy link
Member

@bogdandrutu bogdandrutu Aug 17, 2020

Choose a reason for hiding this comment

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

Still not convinced:

  1. If we go with attributes associated with the "RecordException" then this is not needed, and causes us pain if released for GA and we need to remove;
  2. I would prefer to focus on the current problem with the API which is that all arguments are required because adding new arguments like this should be backwards compatible but removing others is backwards incompatible;

Based on this I would not rush especially now before GA to add new "features" that are not proven - I mean we should have some prototype, etc.

Copy link
Member Author

Choose a reason for hiding this comment

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

and causes us pain if released for GA and we need to remove;

I don't think we will ever have to remove this. If anything this becomes an overload of the function that does a trivial translation to some other overload that accepts an arbitrary number of attributes.
However, we also have the same topic of adding a parameter to RecordException on #822 (although that one looks like it is really not necessary IMHO), so we should discuss this a bit more on that PR, because if RecordException becomes a point where everyone wants to add new attributes, this is bad.

We could resolve #814 by replacing recordException with an optional parameter "exception" to addEvent. WDYT? Then this PR would not need to change either recordException or addEvent.

Copy link
Member Author

Choose a reason for hiding this comment

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

I would prefer to focus on the current problem with the API

That focus is in #814.

Copy link
Member

Choose a reason for hiding this comment

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

That was my point that it looks like there are more ideas about adding new params which, and in some design proposed like using attributes this will become obsolete. Just want to make sure we are not going to have to deprecate this API in 3 months, that is my main concern.

Copy link
Member Author

@Oberon00 Oberon00 Aug 18, 2020

Choose a reason for hiding this comment

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

looks like there are more ideas about adding new params

Agreed, we need to decide on something there before merging (this part of) the PR. EDIT: I don't think this can be sensibly split from this PR, because having just the attribute there without a way to set it with RecordException will make people ask how the RecordException implementation would come up with that value.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think this is resolved now. @bogdandrutu

Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

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

As per comments, blocking this because the focus should be on #814

@github-actions

This comment has been minimized.

@github-actions github-actions bot added the Stale label Aug 30, 2020
@bogdandrutu
Copy link
Member

Should this be updated or dropped now that we have the generic attributes?

@Oberon00
Copy link
Member Author

Oberon00 commented Aug 30, 2020

No, error.hint does not support the same use cases: An escaped exception may still not be an error and vice versa. I will rebase the PR after the weekend 😉

@bogdandrutu
Copy link
Member

bogdandrutu commented Aug 31, 2020

I was referring to generic attributes not to error hint (see https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/api.md#record-exception) so this may be an attribute not a special argument passed to the function

@Oberon00
Copy link
Member Author

Oberon00 commented Sep 1, 2020

@bogdandrutu (#784 (review)):

As per comments, blocking this because the focus should be on #814

You still have a "request changes" on this PR, but #814 is resolved now. Are you still against merging this PR? Otherwise consider dismissing your "request changes" (I understand you are not convinced enough to approve it).

@bogdandrutu
Copy link
Member

I am worried that this API will become extremely different between languages which may be ok as long as semantically they are equivalent, but I do believe that so far we did not allow a choice between having something as a semantic convention vs an API concept, and this being the first time doing this worries me, because we will open a lot of cases like this.

So I would prefer to not open another possibility in the API and decide that everything that is a semantic convention is everywhere, and everything that is an API concept is everywhere. I am worried about consistency between languages.

@bogdandrutu
Copy link
Member

So, indeed this feels like a small change, but as I pointed in the previous comment adds a new "way to implement" specs, so I am worried if this is the right PR to do that. If we want to give that opportunity to the languages we should have it clearly described, and we should discuss it. This is how I see this and that's why I still have required changes

@Oberon00
Copy link
Member Author

Oberon00 commented Sep 2, 2020

@bogdandrutu I removed the API change (under protest!). But please also request changes on the error.hint PR #822 then for the same reasons. I don't want error.hint to become misused as exception.escaped just because it is more convenient to put on the event.

@Oberon00
Copy link
Member Author

Oberon00 commented Sep 2, 2020

Please ping me or @arminru to get this branch updated to merge it (see #512)

@bogdandrutu
Copy link
Member

First thanks for pointing to the other PR, commented there as well. Secondly please update the branch :)

@bogdandrutu
Copy link
Member

I remembered that I have to give people a chance to comment 24h at least since the last change was significant. I will merge tomorrow morning

Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
@Oberon00
Copy link
Member Author

Oberon00 commented Sep 3, 2020

@bogdandrutu There were a few trivial changes (changelog entry added, typos fixed), but I think this is (still) ready to merge.

This pull request was closed.
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 area:semantic-conventions Related to semantic conventions release:after-ga Not required before GA release, and not going to work on before GA spec:trace Related to the specification/trace directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants