You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #5881, there was discussion about the appearance of a possible panic in the internal/global meter package. If we intend to avoid every possibility of a panic due to a misbehaving SDK, then there are other code paths we should look at fixing.
I thought I would document one of these.
Steps To Reproduce
Create an alternate metric SDK, as in the file alternate_meter_test.go from #5881. Have the SDK return nil from any one of its instrument constructors. The internal/global package has (14 cases, presently) code like:
The problem is that ctr can be nil if the SDK misbehaves because the atomic.Value.Store() method immediately panics.
if val == nil {
panic("sync/atomic: store of nil value into Value")
}
Expected behavior
If this is an unacceptable risk, then we should add tests for these 14 cases. If we agree that a misbehaving SDK is responsible for itself, and if the user installs one of those as a global, it's OK to crash, then we can put a note in the code and close this issue.
The text was updated successfully, but these errors were encountered:
Description
In #5881, there was discussion about the appearance of a possible panic in the internal/global meter package. If we intend to avoid every possibility of a panic due to a misbehaving SDK, then there are other code paths we should look at fixing.
I thought I would document one of these.
Steps To Reproduce
Create an alternate metric SDK, as in the file
alternate_meter_test.go
from #5881. Have the SDK returnnil
from any one of its instrument constructors. The internal/global package has (14 cases, presently) code like:The problem is that
ctr
can be nil if the SDK misbehaves because theatomic.Value.Store()
method immediately panics.Expected behavior
If this is an unacceptable risk, then we should add tests for these 14 cases. If we agree that a misbehaving SDK is responsible for itself, and if the user installs one of those as a global, it's OK to crash, then we can put a note in the code and close this issue.
The text was updated successfully, but these errors were encountered: