[ISSUE-5161] Fix panics if a nil context is provided to the .Start() method

[xxbtwxx]

Fix for #5161

As agreed by this discussion, the implementation should not throw unhandled exceptions at run time.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: xxbtwxx / name: Hristo Temelski (eb1a011, affde0d, 0f99c8a, 7298e27, 4351cb3, c7f4d78)

[dmathieu]

Could you add tests?

[MrAlias]

This seems like standard Go behavior. The context package explicitly states nil context should not be used:

I do not think we should be adding boilerplate to all of our functions to prevent invalid user behavior in the eyes of Go.

[xxbtwxx]

This seems like standard Go behavior. The context package explicitly states nil context should not be used:

I do not think we should be adding boilerplate to all of our functions to prevent invalid user behavior in the eyes of Go.

This was previously discussed and agreed upon here

Here's a link to the spec, that says:

API methods MUST NOT throw unhandled exceptions when used incorrectly by end users. The API and SDK SHOULD provide safe defaults for missing or invalid arguments. For instance, a name like empty may be used if the user passes in null as the span name argument during Span construction.

[dmathieu]

I may be doing lawyer talk, but I'm not sure the specification works for this case.

API methods MUST NOT throw unhandled exceptions when used incorrectly by end users.

I read this specification as saying that the SDK's API methods should not throw unhandled exceptions when the SDK's API methods are used incorrectly by end-users.
Not if an external API (in this case, context.Context) is used incorrectly.

This was previously discussed and agreed upon #3110 (comment)

This comment is not an agreement. It's a single approver's opinion (which is not to be dismissed either of course).
cc @dashpole

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.8%. Comparing base (014c6fc) to head (c7f4d78).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #5162   +/-   ##
=====================================
  Coverage   83.8%   83.8%           
=====================================
  Files        254     254           
  Lines      16532   16538    +6     
=====================================
+ Hits       13864   13870    +6     
  Misses      2375    2375           
  Partials     293     293           

Files	Coverage Δ
internal/global/trace.go	85.1% <100.0%> (+0.6%)	⬆️
trace/noop.go	59.0% <100.0%> (+4.0%)	⬆️
trace/noop/noop.go	100.0% <100.0%> (ø)

[xxbtwxx]

I may be doing lawyer talk, but I'm not sure the specification works for this case.

API methods MUST NOT throw unhandled exceptions when used incorrectly by end users.

I read this specification as saying that the SDK's API methods should not throw unhandled exceptions when the SDK's API methods are used incorrectly by end-users. Not if an external API (in this case, context.Context) is used incorrectly.

I would agree with this if the second part of the spec was not included
The API and SDK SHOULD provide safe defaults for missing or invalid arguments.
With a nil context clearly being an invalid argument

[dashpole]

My reading of the spec is that we are required not to panic on nil context for API methods. It is also an improper use of go's Context, but i'm not sure that changes anything.

This comment is not an agreement. It's a single approver's opinion

Thats correct. I'm happy to be overruled by other approvers here.

But I don't think this needs to be a lot of boilerplate, since we don't actually need to add a nil check everywhere. IMO we should just update ContextWithSpan to handle a nil parent context here:

opentelemetry-go/trace/context.go

Lines 13 to 15 in 014c6fc

	func ContextWithSpan(parent context.Context, span Span) context.Context {
	return context.WithValue(parent, currentSpanKey, span)
	}

I've checked all of our metric and trace APIs that accept a context.Context, and all of our usage is either to call trace.SpanFromContext, or trace.ContextWithSpan (or a method that calls one of those two). We already check for nil in trace.SpanFromContext:

opentelemetry-go/trace/context.go

Lines 37 to 40 in 014c6fc

	func SpanFromContext(ctx context.Context) Span {
	if ctx == nil {
	return noopSpanInstance
	}

If we did decide to go that route, it would be good, IMO to add the TestNoPanic tests from this PR, and also to our metrics and logs APIs.

[pellared]

since we don't actually need to add a nil check everywhere

What about all API methods that accepts interfaces like Span, SpanStartOption, TracerOption, Int64CounterOption?

E.g. do we want to add nil-checks in the code below?

opentelemetry-go/metric/asyncint64.go

Lines 108 to 114 in 6628407

	func NewInt64ObservableUpDownCounterConfig(opts ...Int64ObservableUpDownCounterOption) Int64ObservableUpDownCounterConfig {
	var config Int64ObservableUpDownCounterConfig
	for _, o := range opts {
	config = o.applyInt64ObservableUpDownCounter(config)
	}
	return config
	}