Feedback regarding the approach to using the Golang SDK

[smeubank]

Recently we (Sentry) received some feedback regarding the approach to using the Golang sdk

Questions fall generally into two categories:

1. best approach: Applying thread & exception interfaces to their case
2. feedback related to design decisions in the golang sdk.

Description:

• Process A has a black box tool compiled with the program that produces data of interest while process A is running.
• Process A maps to a project in Sentry.
• Process A passes outputs from black box tool into process B.
• Process B wants to send this data to sentry.

When looking for a way to add stack trace data to a sentry payload that isn't from the current process. This includes both exception frames & thread frames which may be different.

Referring to both threads & the optional specification for thread_id in exceptions, this can be interpreted limiting. https://develop.sentry.dev/sdk/event-payloads/exception/#attributes ?

Question:

May I ask why Sentry doesn't allow both a thread stack trace and an exception one? Technically speaking, they don't have to be the same, and in our use case here they aren't.

1. The thread stack indicates where the code was created that caused the exception.
2. while the exception stack trace indicates where the problem itself was/is"

Assuming it is possible for some users to lose out on some organizational conveniences for threads & exceptions in the UI, however there are gains from just sending the data they want?

Feedback

"What's up with frames/slices being in reverse order?"

In response to reversal documented here and discussing this function within the SDK:

sentry-go/client.go

Line 486 in e61b0a4

// event.Exception should be sorted such that the most recent error is last.

The code linked seems to only apply to code that uses CaptureException (which calls CaptureEvent), not code that calls CaptureEvent directly (or any code that creates any Event/slice types itself, which is a lot). Perhaps this slice reordering should occur in the latter, so users of the latter have the correct behavior. Though the most flexible approach may be to remove the reversing from the Go version (server side of Sentry itself and/or the Sentry UI), or have a public function added to the Go version/sdk stating the reversing of all slices needs to occur if calling CaptureEvent or creating event/slice/data yourself.

Point 1 noted, this goes against both the idioms in Go regarding slice order, and the stack trace interfaces Sentry directly supports (as noted in the original email, the errors.StackTrace interface and others explicitly state newest->oldest errors package - github.com/pkg/errors - pkg.go.dev). The latter of which I think is a larger issue as it silently breaks things. There are various open source packages that integrate with Sentry, none of which I've seen are aware of this. For example, this package sentryhook/hook.go at master - makasim/sentryhook - GitHub calls CaptureEvent directly; only if you also happen to; use the default converter, enable auto stack tracing, and do so via an interface Sentry supports (like the link above) then it might be reversed.

I have anonymized this and moved to OS discussions, to gain the opportunity to gather more feedback from the community at large