github.com/getsentry/sentry-go/transport.go:200

Currently the environment integration ships two datapoints about the runtime:

1. Name
2. Version

Can we add two more datapoints provided by default by the lib?
3. Number of goroutines
4. GOMAXPROCS

Has there been a decision to consciously exclude these datapoints from the runtime information provided?

in sentry.go you still have the version constant as

const Version = "0.0.1-beta.3"

This then causes a warning to be shown in the UI about an out of date client SDK

Here is the way I use this package:

1. Init sentry in init func once
2. To report an event I use the following code:

hub := sentry.CurrentHub().Clone()
hub.WithScope(func(s *sentry.Scope) {
  // ...
  hub.CaptureException(err)
  // ...
})

I use the code in multiple goroutines concurrently.

It seems that this package is not goroutine safe as the running program sometimes crashed with message concurrent map writes.

Am I take the wrong way of using the package?

Is there any specific reason that SampleRate is float32?

Most of the packages std/3rd party use float64 unless there is a valid reason.

We've been using 0.0.1-beta.2 for a while successfully. There was a message in the Sentry console today that we should update to 0.1.0 so we did. Local testing seemed fine but when running in an actual environment (Lambda based) for some reason it short circuited all processing of the function. Rolling back to the older version resolved it. Any idea what may be causing this? Are there code changes we should be making to get on to the current version?

I noticed this issue after upgrading to v0.0.1-beta.2. I've added a test to confirm

😄

Quoting @kataras from #78 (comment):

Recommendation

Please rename your ./example directory to ./_examples and use a different go.mod and go.sum files for each of the web frameworks provided there, this way your library will not depend on unnecessary third-parties as _ prefix can be go-skipped.

Thanks,
Gerasimos Maropoulos. Author of the Iris Web Framework.

In raven-go if you pass the headers using raven.Http like so:

headersMap := make(map[string]string)

// add headers
...

raven.SetHttpContext(&raven.Http{
Method: "GET",
URL: "https://example.com/raven-go",
Headers: headersMap,
})

Sentry and/or Raven-Go client infers lots of useful info such as device, browser, os, etc for each event. Using the migration guide here I'm not seeing a clear way to do this and have the same info appear. Is this possible with the new client?

I just started integrating sentry-go and found the documentation on sentry.Recover slightly light

Specifically:

• I only found it because Google took me to https://docs.sentry.io/platforms/go/migration/ (which I hadn't read, because I was a new sentry-go user, not migrating from Raven) - it doesn't appear in the regular sentry-go docs
• Common usage scenarios/issues like #30 aren't documented either (much like @DimitriosLisenko, I couldn't get the simple defer sentry.Recover() example provided to actually ever result in an error reaching Sentry)

I'd love to see the usage docs improved here, with some canonical examples and references please!

Often times in larger applications one will use wrappers around loggers, alerters, mailers, etc. to not tie the application code to a specific implementation.

As a crude example..

func (a *alertWrapper) Error(err error) error {
	sentry.CaptureException(err)
	return err
}

In sentry the first stackframe will always report the wrapper code as the caller, followed by subsequent frames which we are actually interested in.

Instead of the approach outlined in #35 would you consider adding an option to directly skip n number of frames. 99% of the time it'd likely be 1, but this would make the API slightly more generous :)

hello, I'm just wondering how the stacktrace reporting works with the sentry-go client?

it appears my source code is being recorded in sentry's servers, which is quite concerning as our company source is private. I'd like it to only record+report the raw stacktrace as the standard go stacktrace prints in a binary.

please let me know as we can't use sentry-go until this is clarified. thanks

Is it possible to suppress the default contexts set when preparing an event?

I couldn't find (or missed) if this is possible from the docs:

https://docs.sentry.io/enriching-error-data/context/?platform=go

E.g., I created a wrapper around sentry

func (a *alertWrapper) Error(err error) error {
	hub := sentry.CurrentHub().Clone()
        hub.ConfigureScope(func(scope *sentry.Scope) {

        }
}

I can set tags and new contexts inside the ConfigureScope closure, but, is it possible to remove or modify underlying contexts to alter what appears in the GUI?

Hello everyone,
Trying to use request body logging in some cases, but it doesn't seem to be working

request := sentry.Request{}
request = request.FromHTTPRequest(req)

request.Data is always empty :(

I guess a problem can be here

if request.GetBody != nil {
		if bodyCopy, err := request.GetBody(); err == nil && bodyCopy != nil {
			body, err := ioutil.ReadAll(bodyCopy)
			if err == nil {
				r.Data = string(body)
			}
		}
	}

request.GetBody is always == nil and Doc says

For server requests, it is unused.

request.Body looks like a right field.

Given the recent issues related to using sentry-go with multiple goroutines and my recent patches, I've been thinking perhaps it would be possible to draw a line and have some parts of the API safe for concurrent use, and some others intentionally not safe, for simplicity, performance and flexibility.

Opening this issue to discuss this idea, and validate whether it could be of advantage for users and maintainers.

Background

As an example of the safe/unsafe APIs, let's consider the math/rand package in the Go standard library.

The default [global] Source is safe for concurrent use by multiple goroutines, but Sources created by NewSource are not.

Similar to sentry-go, math/rand has a global-scope API for convenient usage:

rand.Seed(42)
fmt.Println(rand.Int())

Many users will call global functions in the rand package and those are all safe for concurrent use, using the default random source. That's probably the common and simple use case.

Now, if one needs flexibility to have multiple random number generators with different seeds and use them concurrently, we can, as long as we create a new source and use it from a single goroutine:

https://play.golang.org/p/6tAa1lVTcKe

var wg sync.WaitGroup
wg.Add(10)
for i := 0; i < 10; i++ {
	go func(i int) {
		defer wg.Done()
		r := rand.New(rand.NewSource(int64(i)))
		fmt.Printf("Goroutine #%d: %d\n", i, r.Int())
	}(i)
}
wg.Wait()

rand.NewSource returns a lock-free value implementing the rand.Source interface.

sentry-go's API

Similar to math/rand, sentry-go could offer a default, global, Hub/Scope/Client that is safe for concurrent use, and that will cover the simple use cases when people just need to get something working.

That is, after calling sentry.Init(...), calls to top-level functions such as sentry.AddBreadcrumb, sentry.CaptureMessage, etc, should be safe for concurrent use.

In the recent efforts those are already becoming more and more safe, possibly still some cases to cover.

With the global API being safe, there is room for a lock-free API either for more complicated use cases that would let users do their own synchronization without paying the costs of having locks in the library's API, or for users that need to optimize the performance of their error reporting.

For example, if a Hub/Scope/Client is meant for use in a single goroutine, after copying it we need no locks when sending messages, errors, etc over the network, or changing goroutine-local configuration like tags and breadcrumbs.

In this usage, each goroutine would have their own private lock-free "Hub" or "Scope" or "Client" (haven't thought through the details).

Thoughts?

This way we don't have to unnecessarily use interface{} or pile up random attributes on EventHint and BreadcrumbHint, as well as Hint would always be there.

BeforeSend: func(event *sentry.Event, hint context.Context) *sentry.Event {
	if someValue, ok := hint.Value(someKey).(someframework.Context); ok {
		// Do some work
	}

	return event
},

Hi,

Sentry-go has almost 40 indirect dependencies
https://github.com/getsentry/sentry-go/blob/master/go.mod

which makes a binary package for primitive < 5MB applications quite big

is there a way to work around this, (some sort of lightweight minimal client ?) or do we have HTTP client for Sentry that we can use? thanks

Transports don't handle marshaling errors and send empty events without any alert. The server just ignores requests like that. This means that messages are simply lost without any alerts.

It would be better if in case of an error it displayed in debug log or something like that.

Simple way to reproduce:

hub := sentry.CurrentHub().Clone()
hub.ConfigureScope(func(scope *sentry.Scope) {
	type test struct {
		UnsupportedField func()
	}
	scope.SetExtra(`test`, test{})
})
hub.CaptureMessage("broken event")
hub.Flush(5*time.Second)

Startup of the client with noopTransport when the DSN is empty I think is dangerous in some cases.

I would suggest to introduce an option to disable this mode. A breaking change on the API can be avoided maintaining the current mode with the noopTransport as the default way.

Hello everyone,
I've tried to update the sentry-go version to 0.3.1 and got an error:

build app: cannot load github.com/ugorji/go/codec: ambiguous import: found github.com/ugorji/go/codec in multiple modules:
	github.com/ugorji/go v1.1.4 (/go/pkg/mod/github.com/ugorji/[email protected]/codec)
	github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8 (/go/pkg/mod/github.com/ugorji/go/[email protected])

I've changed in go.mod of my project github.com/getsentry/sentry-go v0.3.0 to github.com/getsentry/sentry-go v0.3.1

Here are the ugorji entries in go.sum:

github.com/ugorji/go v1.1.1/go.mod h1:hnLbHMwcvSihnDhEfx2/BzKp2xb0Y+ErdfYcrs9tkJQ=
github.com/ugorji/go v1.1.4 h1:j4s+tAvLfL3bZyefP2SEWmhBzmuIlH/eqNuPdFPgngw=
github.com/ugorji/go v1.1.4/go.mod h1:uQMGLiO92mf5W77hV/PUCpI3pbzQx3CRekS0kk+RGrc=
github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8 h1:3SVOIvH7Ae1KRYyQWRjXWJEA9sS/c/pjvH++55Gr648=
github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8/go.mod h1:VFNgLljTbGfSG7qAOspJ7OScBnGdDN/yBr0sguwnwf0=

go version is 1.13

What Sentry version(s) is this new SDK Go compatible with, e.g., 8.x.x, 9.x.x ?

https://travis-ci.com/getsentry/sentry-go/builds/136111144

We are attempting to use the same Sentry client in a server with many goroutines, as we assumed this client was thread-safe. However, we're getting "concurrent map writes" errors.

1. Is the Sentry client intended to be thread-safe? Specifically, is it intended to be safe to concurrently send events to the client returned by sentry.NewClient?

2. If yes, then we have found a bug: the contextifyFramesIntegration in integrations.go is not thread-safe. In particular, it has a cachedLocations variable which is a map, and access to this variable is not synchronized. We're getting stack traces from the concurrent map writes errors that point to reads/writes of this map.

I noticed that sourceReader has a similar caching mechanism, but that one is protected by a mutex....

We're using the Sentry client from commit 510f01e, but I don't see anything fixed in the latest master, either.

In the docs, it is recommended that you call

defer sentry.Recover()

before running code that may panic.

However, it doesn't look like the framework actually waits for the error to be sent upstream. Modifying the sentry.Recover() code to call sentry.Flush(...) before returning the event ID resolves this issue.

I have added a provisional PR that resolves this here: #31.
If you have ideas for other approaches, or would like to make the Flush time configurable, let me know there.

Hi there!

I did want to use sentry in my middleware.

func InitTracker() {
	rate, _ := strconv.ParseFloat(os.Getenv("SENTRY_SAMPLE_RATE"), 32)
	err := sentry.Init(sentry.ClientOptions{
		Dsn: os.Getenv("SENTRY_DSN"),
		Environment: os.Getenv("SENTRY_ENVIRONMENT"),
		Release: os.Getenv("SENTRY_RELEASE"),
		DebugWriter: os.Stderr,
		Debug: true,
		SampleRate: float32(rate),
	})

	if err != nil {
		fmt.Printf("Sentry initialization failed: %v\n", err)
	}
}

func LoggerWithSentry() echo.MiddlewareFunc {
	return func(next echo.HandlerFunc) echo.HandlerFunc {
		return func(ctx echo.Context) (err error) {

			req := ctx.Request()
			res := ctx.Response()

			if err = next(ctx); err != nil {
				ctx.Error(err)
			}

			if res.Status >= http.StatusBadRequest {

				var errCtx = map[string]string{
					"UserAgent": req.UserAgent(),
					"Referer": req.Referer(),
					"ResponseCode": string(res.Status),
				}

				var requestCtx = map[string]string{
					"Method": req.Method,
					"URL": req.URL.RawPath,
					"Query": req.URL.RawQuery,
				}

				var userCtx = sentry.User{
					IPAddress: ctx.RealIP(),
				}

				sentry.WithScope(func(scope *sentry.Scope) {
					scope.SetTags(errCtx)
					scope.SetContext("Request", requestCtx)
					scope.SetUser(userCtx)
					sentry.CaptureException(err)
					scope.Clear()
				})
			}

			return next(ctx)
		}
	}
}

Finally, I got exception

{"time":"2019-05-26T13:43:50.104382363Z","level":"-","prefix":"echo","file":"recover.go","line":"73","message":"[PANIC RECOVER] reflect: call of reflect.Value.MethodByName on zero Value goroutine 30 [running]:\ngithub.com/labstack/echo/v4/middleware.RecoverWithConfig.func1.1.1(0xa0c470, 0x1000, 0xc000060000, 0xab8180, 0xc0000e4cb0)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/labstack/echo/v4/middleware/recover.go:71 +0xf1\npanic(0x911ae0, 0xc0003db8a0)\n\t/app/tmp/cache/go1.12.5/go/src/runtime/panic.go:522 +0x1b5\nreflect.Value.MethodByName(0x0, 0x0, 0x0, 0x9a4f74, 0xe, 0xc0001c57d8, 0xc0004fa240, 0xc0004f1980)\n\t/app/tmp/cache/go1.12.5/go/src/reflect/value.go:1277 +0x1b5\ngithub.com/getsentry/sentry-go.extractReflectedStacktraceMethod(0x0, 0x0, 0x8, 0x10, 0xc00041d2f0)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/stacktrace.go:78 +0xe7\ngithub.com/getsentry/sentry-go.ExtractStacktrace(0x0, 0x0, 0x60)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/stacktrace.go:51 +0x39\ngithub.com/getsentry/sentry-go.(*Client).eventFromException(0xc000232e10, 0x0, 0x0, 0x9a06a0, 0x5, 0xc0002bef00)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/client.go:241 +0x39\ngithub.com/getsentry/sentry-go.(*Client).CaptureException(0xc000232e10, 0x0, 0x0, 0xc0002bef00, 0xaa0480, 0xc00046b3f0, 0xc00041d2f0)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/client.go:172 +0x58\ngithub.com/getsentry/sentry-go.(*Hub).CaptureException(0xc0002ce4a0, 0x0, 0x0, 0x7)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/hub.go:173 +0xfe\ngithub.com/getsentry/sentry-go.CaptureException(...)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/api.go:37\ngithub.com/kotovskyart/edera-api/shared/kernel.LoggerWithSentry.func1.1.1(0xc00046b3f0)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/shared/kernel/middleware.go:71 +0x2d5\ngithub.com/getsentry/sentry-go.(*Hub).WithScope(0xc0002ce4a0, 0xc0001c5ab0)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/hub.go:132 +0x6e\ngithub.com/getsentry/sentry-go.WithScope(...)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/getsentry/sentry-go/api.go:82\ngithub.com/kotovskyart/edera-api/shared/kernel.LoggerWithSentry.func1.1(0xab8180, 0xc0000e4cb0, 0x0, 0x0)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/shared/kernel/middleware.go:60 +0x3c4\ngithub.com/labstack/echo/v4/middleware.RecoverWithConfig.func1.1(0xab8180, 0xc0000e4cb0, 0x0, 0x0)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/labstack/echo/v4/middleware/recover.go:78 +0xd5\ngithub.com/labstack/echo/v4.(*Echo).ServeHTTP(0xc000456380, 0xaa9480, 0xc00048c1c0, 0xc00019ce00)\n\t/tmp/build_39d9da06f2d4785aacc77b42833ee49d/vendor/github.com/labstack/echo/v4/echo.go:593 +0x221\nnet/http.serverHandler.ServeHTTP(0xc00013a0d0, 0xaa9480, 0xc00048c1c0, 0xc00019ce00)\n\t/app/tmp/cache/go1.12.5/go/src/net/http/server.go:2774 +0xa8\nnet/http.(*conn).serve(0xc00013c780, 0xaaa640, 0xc00026ad00)\n\t/app/tmp/cache/go1.12.5/go/src/net/http/server.go:1878 +0x851\ncreated by net/http.(*Server).Serve\n\t/app/tmp/cache/go1.12.5/go/src/net/http/server.go:2884 +0x2f4\n\ngoroutine 1 [IO wait]:\ninternal/poll.runtime_pollWait(0x7fd0586e7dd8, 0x72, 0x0)\n\t/app/tmp/cache/go1.12.5/go/src/runtime/netpoll.go:182 +0x56\ninternal/poll.(*pollDesc).wait(0xc000138218, 0x72, 0x0, 0x0, 0x9a1646)\n\t/app/tmp/cache/go1.12.5/go/src/internal/poll/fd_poll_runtime.go:87 +0x9b\ninternal/poll.(*pollDesc).waitRead(...)\n\t/app/tmp/cache/go1.12.5/go/src/internal/poll/fd_poll_runtime.go:92\ninternal/poll.(*FD).Accept(0xc000138200, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)\n\t/app/tmp/cache/go1.12.5/go/src/internal/poll/fd_unix.go:384 +0x1ba\nnet.(*netFD).accept(0xc000138200, 0xb4, 0x203000, 0x203000)\n\t/app/tmp/cache/go1.12.5/go/src/net/fd_unix.go:238 +0x42\nnet.(*TCPListener).accept(0xc0003f40a8, 0xc000034500, 0x40d499, 0xc00013c780)\n\t/app/tmp/cache/go1.12.5/go/src/net/tcpsock_posix.go:139 +0x32\nnet.(*TCPListener).AcceptTCP(0xc0003f40a8, 0x8c05c6ee, 0x5f229440908c2f94, 0x44b7d8)\n\t/app/tmp/cache/go1.12.5/go/src/net/tcpsock.go:247 +0x48\ngithub.com/labstack/echo/v4.tcpKeepAl\n"}

I am using github.com/pkg/errors and all errors show up in Sentry with the title *errors.WithStack. Is there any way of customizing this message so that it's more informative? The full error message is shown below but it's hard to differentiate issues when they all have the same title.

Using Sentry 9.1.2 on the server side.

According to the docs only the Python and PHP sdks will include local variables in frames of stack traces.
Any planned support for including this in the Go sdk? If not, can you explain the reasons?

Logrus is likely the most popular logging library in Go (https://github.com/sirupsen/logrus), with over 10k stars.

Since sentry-go already supports some web frameworks, it will be great if there can be out-of-the-box support for logrus too.

Using the following code in an AWS Lambda running the Go 1.x image (Amazon Linux) the generated output is empty:

stacktrace := sentry.NewStacktrace()

Running the same command on a Mac dev machine returns the expected stack.

This is how it should work from the beginning and this is how it works in JS SDK.

Change here:

When using sentry in a go project, which is statically compiled and executed in a docker scratch image sentry captured errors will not end up in the webinterface.

Generated a panic and it was sent to sentry via Recover. I see a bit of info here but no stacktrace, without which it's quite tough of course to determine the source/cause of the issue

I suggest to add logging here (via Logger) https://github.com/getsentry/sentry-go/blob/v0.0.1-beta/transport.go#L97 - otherwise there is no info about dropped packets when using debug mode. Dropped packets are just logged as being sent in https://github.com/getsentry/sentry-go/blob/v0.0.1-beta/transport.go#L85.

Shouldn't a sentry.Flush() call fail if there were some dropped packets? Currently it does not. I know this is no common use case, since usually non-blocking calls would be used and Flush might not hit the buffer size.

Furthermore it would be great to configure the request worker buffer size https://github.com/getsentry/sentry-go/blob/v0.0.1-beta/transport.go#L16

Thanks for your work! We currently evaluate Sentry & this Go client.

From #78 (comment)

Need an example to reproduce the issue, I'm sorry I don't have time to do it now.
Maybe it is not even a problem, though go.mod may be read by humans and serve as a sort of documentation as to what version of Go is "required" by the library.

Please add release with #59

I'm currently working on migrating to this Sentry Go client from the old raven-go.
Earlier, we were using a combination of sync CaptureErrAndWait and async CaptureError methods. Naturally, this was useful for ensuring that all the events are delivered to Sentry before exiting from the program.

Is there a way to ensure that all events captured by the non-blocking HTTPTransport client using CaptureException are delivered to Sentry?
While reading the examples, I came across the Flush method. However, it essentially times-out after a certain time duration.

A possible solution would be to return a channel to the caller so that they can wait/block until all the buffered events are reported to Sentry.

Gin's default recovery handler is clever about ignoring broken pipe errors, to avoid logging/alerting when no response will be sent because the connection has already closed. The current gin/sentry integration doesn't handle this case and we get false positive sentry alerts due to broken pipes. Integrating this check should be just a few lines of code; see https://github.com/gin-gonic/gin/blob/master/recovery.go#L45

Hi, I am trying to migrate from the old raven client and using that client, one could call SetDefaultLoggerName to set the logger name for the event. It's possible I am missing something, but I can't seem to find a way to set this value in the sentry-go. Is this currently possible?

We use this functionality to make it easier to discern events from different components in our code. If it is currently not possible, any suggestions for a similar solution would be much appreciated.

Is this project open to contributions?

It is impossible to use the Update project method to rename a project. Sending an object requires us to use the current slug. we can update the Name property but this one maps to the Legacy Name.

The current implementation use the slug from the object. Instead, the slug should be a separate parameter UpdateProject(o Organization, projectSlug string, p Project)

// UpdateProject takes a organization and project then updates it on the server side
func (c *Client) UpdateProject(o Organization, p Project) error {
	return c.do("PUT", fmt.Sprintf("projects/%s/%s", *o.Slug, *p.Slug), &p, &p)
}

I am trying to integrate sentry for go routines. Based on this blog post, https://blog.sentry.io/2019/08/15/introducing-sentrys-unified-go-sdk , it seems that each go routine will have to have their own sentry integration using Hub to capture events, panics etc.
Is there an example where I can integrate sentry in a go routine to capture events, panics etc in other go routines? Basically, I dont want to force every go routine to have sentry integration and trying to see if there is a more elegant solution

This issue is a feature request.

It's possible to override the http.Transport via the HTTPTransport field in ClientOptions.

Instead, it would be great to allow to override the http.Client, or http.RoundTripper (which is an abstract http.Transport). This feature would allow users of this package to add hooks at the http level.

When can we expect a stable release?

Similar to https://github.com/getsentry/sentry-javascript/blob/master/packages/integrations/src/rewriteframes.ts

Example usage:

event = sentry.RewriteFrames(event, func (frame *sentry.Frame) *sentry.Frame {
	// Filter all frames from our custom error wrapper to cleanup the stacktrace
	if strings.Contains(frame.Module, "customErrorWrapper") {
		return nil
	}
	return frame
})

re: #38

Hey, we are trying to use the new API, and we are a little confused about the intended usage of a Client, Hub, and Scope. According to https://docs.sentry.io/platforms/go/goroutines/, we should be cloning a hub for each goroutine. That makes sense - it maps to making a clone for each concurrent transaction. However, there are a few things that aren't clear:

• Within a transaction, we might use multiple goroutines; they share the same high level information (eg. they are working on the same operation, same user, etc.) but they might report errors independently; can we add information to the Hub concurrently?

• What is the difference between a Scope and a Hub? We are avoiding global variables so our code is testable, so we are making a new Hub for our client using NewHub. But that function is also asking for a Scope. Do we need to make a new Scope? What information should we add to the Scope vs the Hub?

• In our integration tests, how can we verify that an error was reported correctly in tests?

• We have some middleware that can see the HTTP status code of a response, and reports to Sentry whenever it sees a server error. Some handlers also have error stack trace info available, which we'd like to add-on - but we don't want to report an error twice. Any suggestions on how to do that?

Thanks!

The current raven-go has a major flaw for on-prem hosting of Sentry. In an enterprise situation, the Sentry is likely to be behind an internally signed SSL certificate. As raven-go using the https://github.com/certifi/gocertifi as it's ONLY source of CA certs, it would refuse to talk to the Sentry.

Please make sure that this new package supports disabling of SSL certificate verification. And optionally allow CA certificate to be read from the root.

What series of calls could be used to determine if Sentry had been previously initialized?

Hi,

with the old raven client it was possible to manipulate stack to remove useless caller information (like frameworks, hooks, middleware, ...). With the new client, I can't find how to achieve the same:

stack := raven.NewStacktrace(1, 3, nil)
exc := raven.NewException(err, stack)

Please provide the possibility for working with stacktrace, or document how to do this with the current lib.
Thank you!