thezeroslave / zapsentry Goto Github PK

Is there a way to skip caller path by X number? Currently this also captures zapsentry's (*core).Write, which confuses the issues on Sentry:

Hi there,
I currently have all my systems using logging middleware to log errors. This means that the stack trace associated with the error log is not relevant and is always fixed because it is using the call stack from the middleware, not where the error is raised.

Many errors have the ability to capture their stack trace at the time they were created.
It would be great to have the zapsentry.core{} be customizable in order to extract the stack trace from the given []zapcore.Field.

I believe this is the code that would need changing:

		if event.Exception == nil && !c.cfg.DisableStacktrace && c.client.Options().AttachStacktrace {
			stacktrace := sentry.NewStacktrace()
			if stacktrace != nil {
				stacktrace.Frames = filterFrames(stacktrace.Frames)
				event.Threads = []sentry.Thread{{Stacktrace: stacktrace, Current: true}}
			}
		}

Rather than using sentry.NewStacktrace(), it we could call a customizable function that accepts the []zapcore.Field from the core.Write() method. The default implementation could just call sentry.NewStacktrace() but in my situation, I can look for the error in any of the []zapcore.Fields that are errors.

If this is something that you think would be valuable and if you think this is the right approach, I would be happy to create a PR.

I think it blocked in there.

Something about .addExceptionsFromError doesn't seem to play nice with error chain:

panic: runtime error: hash of unhashable type multierror.chain

goroutine 1 [running]:
github.com/TheZeroSlave/zapsentry.(*core).addExceptionsFromError(0xc000030be0, {0xc000030c30, 0x0, 0x1}, 0xc00016c870, {0xf25f20, 0xc00062c820})
        /home/runner/go/pkg/mod/github.com/!the!zero!slave/[email protected]/core.go:152 +0xf1
github.com/TheZeroSlave/zapsentry.(*core).createExceptions(0xc000030be0)
        /home/runner/go/pkg/mod/github.com/!the!zero!slave/[email protected]/core.go:126 +0x19c
github.com/TheZeroSlave/zapsentry.(*core).Write(0xc000031b30, {0x2, {0xc07c2f23013d5cb7, 0x38836a63, 0x1505080}, {0x0, 0x0}, {0xe18e3b, 0x11}, {0x1, ...}, ...}, ...)
        /home/runner/go/pkg/mod/github.com/!the!zero!slave/[email protected]/core.go:94 +0x56e
go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc00064fec0, {0xc00061be00, 0x1, 0x1})
        /home/runner/go/pkg/mod/go.uber.org/[email protected]/zapcore/entry.go:220 +0x26d
go.uber.org/zap.(*Logger).Error(0xc000238ae0, {0xe18e3b, 0x11}, {0xc00061be00, 0x1, 0x1})
        /home/runner/go/pkg/mod/go.uber.org/[email protected]/logger.go:208 +0x76
github.com/zllovesuki/t/server.(*Server).Gossip(0xc000122500)
        /home/runner/work/t/t/server/gossip.go:32 +0x252
main.main()
        /home/runner/work/t/t/cmd/server/main.go:294 +0x363b

The culprit seems to be this

For me is very interesting how to use sentry for multiple events(error, fatal & panic)? Because right now I see only one posibility to handle only like this:
Level: zapcore.FatalLevel,
EnableBreadcrumbs: true,
BreadcrumbLevel: zapcore.ErrorLevel,

While inspecting this package, I realized that it may not fully support the recommended way to handle concurrency with Sentry.

In particular, Sentry recommends cloning Hubs in goroutines. Also, Sentry leverages Hub cloning for most request-based integrations.

On the other hand, this package seems to leverage fetching and setting scopes and interacts directly with the client rather than the hub.

I'm still trying to wrap my head around all this, but would it be more appropriate to support setting and fetching hubs in addition to or instead of manipulating scopes as fields?

Looking at the sentry code, cloning a hub seems to simply clone the scope, so it's not functionally different, but it may be nice to have a hub-compatible API so that it aligns with the Sentry docs.

Hey!

It would be nice to respect zapcore.Entry.LoggerName, as it is done in zap itself.
See zapcore.EncoderConfig.NameKey.

When logging multiple events via zap in a small time frame, the event which zapsentry builds uses a shared map which causes the scope tag copying to apply concurrently and cause a fatal error.

goroutine 10638 [running]:
runtime.throw({0x27d98f6?, 0xffffffffffffffff?})
        /usr/local/go/src/runtime/panic.go:992 +0x71 fp=0xc00151b6a0 sp=0xc00151b670 pc=0x43f951
runtime.mapassign_faststr(0x24ae960, 0xc00086b710, {0x27b7fbc, 0x4})
        /usr/local/go/src/runtime/map_faststr.go:295 +0x406 fp=0xc00151b710 sp=0xc00151b6a0 pc=0x4176c6
github.com/getsentry/sentry-go.(*Scope).ApplyToEvent(0xc0001a6000, 0xc0000f0b40, 0x0)
        /home/supaham/go/pkg/mod/github.com/getsentry/[email protected]/scope.go:355 +0x1293 fp=0xc00151bb00 sp=0xc00151b710 pc=0x9f1853
github.com/getsentry/sentry-go.(*Client).prepareEvent(0xc0004ac160, 0xc0000f0b40, 0x0, {0x2c4dfc0, 0xc0001a6000})
        /home/supaham/go/pkg/mod/github.com/getsentry/[email protected]/client.go:604 +0xba3 fp=0xc00151cc40 sp=0xc00151bb00 pc=0x9e34e3
github.com/getsentry/sentry-go.(*Client).processEvent(0xc0004ac160, 0xc0000f0b40, 0x0, {0x2c4dfc0, 0xc0001a6000})
        /home/supaham/go/pkg/mod/github.com/getsentry/[email protected]/client.go:539 +0x49a fp=0xc00151d200 sp=0xc00151cc40 pc=0x9e22ba
github.com/getsentry/sentry-go.(*Client).CaptureEvent(0xc0004ac160, 0xc0000f0b40, 0x0, {0x2c4dfc0, 0xc0001a6000})
        /home/supaham/go/pkg/mod/github.com/getsentry/[email protected]/client.go:365 +0x54 fp=0xc00151d248 sp=0xc00151d200 pc=0x9e09f4
github.com/TheZeroSlave/zapsentry.(*core).Write(0xc000d86cd0, {0x2, {0xc0a1f0792157285e, 0xa0fd4bdfb, 0x3e68220}, {0x0, 0x0}, {0x27bb9ae, 0x7}, {0x1, ...}, ...}, ...)
        /home/supaham/go/pkg/mod/github.com/!the!zero!slave/[email protected]/core.go:104 +0x76c fp=0xc00151d878 sp=0xc00151d248 pc=0x12675ec
go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc0007c92c0, {0xc000fc2700, 0x2, 0x4})
        /home/supaham/go/pkg/mod/go.uber.org/[email protected]/zapcore/entry.go:220 +0x35c fp=0xc00151daf8 sp=0xc00151d878 pc=0x69c05c
go.uber.org/zap.(*SugaredLogger).log(0xc000010278, 0x2, {0x27bb9ae, 0x7}, {0x0, 0x0, 0x0}, {0xc003233e50, 0x4, 0x4})
        /home/supaham/go/pkg/mod/go.uber.org/[email protected]/sugar.go:227 +0x185 fp=0xc00151db88 sp=0xc00151daf8 pc=0x9320a5
go.uber.org/zap.(*SugaredLogger).Errorw(0xc000010278, {0x27bb9ae, 0x7}, {0xc0083e5e50, 0x4, 0x4})
        /home/supaham/go/pkg/mod/go.uber.org/[email protected]/sugar.go:191 +0x68 fp=0xc00151dbe8 sp=0xc00151db88 pc=0x931c08

Hi! I'm trying to use breadcrumbs and record the request itself in each event.
Checking the docs it seems I should use this module, that create one hub per request:
https://docs.sentry.io/platforms/go/http/
But, as far as I can see, it isn't possible to integrate that module with zapsentry, since zapsentry always get the global hub:

Hi there 👋
Please consider updating the SDK. The latest stable version is v0.10.0
There are a number of bug fixes (see changelog)

I've encountered an issue with the latest release, v1.22.0. When attempting to log errors that do not contain a stack trace using zap.Error, a panic occurs. This seems to be caused by a lack of nil check for stack traces when errors are logged, and the library attempts to retrieve a stack trace from an error that does not include one.

Steps to Reproduce

• Use version v1.22.0
• Attempt to log an error using zap.Error for an error that does not include a stack trace.
• Observe the panic.

Link to Suspected Cause in Code

Minimal Reproduction Code

package main

import (
	"errors"

	"github.com/TheZeroSlave/zapsentry"
	"github.com/getsentry/sentry-go"
	"go.uber.org/zap"
	"go.uber.org/zap/zapcore"
)

func main() {
	log, _ := zap.NewDevelopment()
	client, _ := sentry.NewClient(sentry.ClientOptions{})
	core, _ := zapsentry.NewCore(
		zapsentry.Configuration{
			Level: zapcore.ErrorLevel,
		},
		zapsentry.NewSentryClientFromClient(client),
	)
	log = zapsentry.AttachCoreToLogger(core, log)
	log.Error("Error log", zap.Error(errors.New("error message")))
}

Output of Minimal Reproduction Code

$ go run main.go
2024-04-02T12:49:07.659+0900    ERROR   gostudy-zapsentry/main.go:22    Error log       {"error": "error message"}
main.main
        /go/src/github.com/mackee/sandbox/gostudy-zapsentry/main.go:22
runtime.main
        /go/sdk/go1.22.1/src/runtime/proc.go:271
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xc077ccd]

goroutine 1 [running]:
github.com/TheZeroSlave/zapsentry.(*core).addExceptionsFromError(0xc00007e2d0, {0xc00007e320?, 0x10?, 0x10?}, 0xc0000415c8, {0xc1a6fc8?, 0xc000024750?})
        /go/pkg/mod/github.com/!the!zero!slave/[email protected]/core.go:223 +0x1ad
github.com/TheZeroSlave/zapsentry.(*core).createExceptions(0xc00007e2d0)
        /go/pkg/mod/github.com/!the!zero!slave/[email protected]/core.go:183 +0x108
github.com/TheZeroSlave/zapsentry.(*core).Write(0xc00007e280, {0x2, {0xc17afdece74afd90, 0x14324e3, 0xc3c7760}, {0x0, 0x0}, {0xc07b307, 0x9}, {0x1, ...}, ...}, ...)
        /go/pkg/mod/github.com/!the!zero!slave/[email protected]/core.go:143 +0xafe
go.uber.org/zap/zapcore.(*CheckedEntry).Write(0xc00010f930, {0xc000046700, 0x1, 0x1})
        /go/pkg/mod/go.uber.org/[email protected]/zapcore/entry.go:253 +0x11c
go.uber.org/zap.(*Logger).Error(0xc1aa9a0?, {0xc07b307?, 0xc000130a00?}, {0xc000046700, 0x1, 0x1})
        /go/pkg/mod/go.uber.org/[email protected]/logger.go:263 +0x51
main.main()
        /go/src/github.com/mackee/sandbox/gostudy-zapsentry/main.go:22 +0x218
exit status 2