Error flagging with status codes

[tedsuo]

This proposal attempts to address error handling while making the least number of breaking changes to our current system. It retains SpanStatus. Other proposals we essentially reinventing it, only in a way that would introduce a number of breaking changes. It allows current instrumentation to continue to work as-is, while providing guidance to instrumentation authors. It includes a way to differentiate between the default errors provided by instrumentation and intentional error flagging provided by the end user.

If accepted, this proposal would replace OTEP #134, and addresses issues #559 and #706.

[Oberon00]

All in all, looks sensible to me.

[carlosalberto]

Overall looks good to me.

[tigrannajaryan]

Ted, thank you for the proposal. I think this nicely summarizes the Error WG discussion. I have a few questions/comments that would be good to clarify.

[justinfoote]

In my opinion, this is a reasonable compromise and logical step forward. Thanks for writing it up!

[tedsuo]

FYI I have updated this proposal based on feedback. Rather than adding additional status codes to represent user overrides, we add a user_override boolean which indicated that the end user has confirmed that the status code is correct. The expected behavior is that the status code on the span should take precedence over any further analysis.

Please let me know if this solves our remaining issues with error reporting.

[arminru]

Mostly editorial suggestions and some statements that need to be clarified but nothing to object. I'm satisfied with the general direction and agree with @tigrannajaryan that, given the initial consensus we have here, we'll be able to work out the details in the spec (and proto) PRs.

[tedsuo]

Thanks @arminru. I adjusted the language to clarify the points you raised. Is this good enough to merge?

[arminru]

LGTM! The details will be sorted out when this is poured into a spec PR. Thanks Ted!

[carlosalberto]

Merging this as we have enough votes and don't want to decrease the velocity - and as @arminru said, we will iron out the actual details in the Specification.

cc @bogdandrutu

[bogdandrutu]

@carlosalberto not that I am totally against this (I would probably request changes in that case) but as mentioned multiple times, we cannot use the velocity argument to merge changes before GA because that may cost us a lot in the future if we merge half baked changes now to rush things.

[carlosalberto]

@bogdandrutu Oh, definitely. I merged cause this is 'merely' an OTEP, but let's definitely find full agreement when the actual changes hit the Specification (as long as they take).

[tedsuo]

@bogdandrutu: I agree, but to be clear, this was merged because it had more than enough votes, was open for an acceptable amount of time, and there were no further objections.