How to change a struct field of a core in a multiCore logger?

[cideM]

We're trying to extend Zap by making it send errors to Sentry through a new zapcore.Core. We have a middleware that gets the current Sentry hub, plus some other data specific to each request, from the request context. We then clone the Sentry hub and would like to now update the Sentry hub that is stored in our custom Zap core.

In main.go we initialize the logger and wrap it with our core:

sentryCore := sentrycore.New()

loggerConfig := logging.ZapConfig() // "logging" just has our shared configuration, nothing special
loggerConfig.Level = logLevel

logger, err := loggerConfig.Build()
if err != nil {
  log.Fatal(err)
}

withSentry := zap.WrapCore(func(c zapcore.Core) zapcore.Core {
  return zapcore.NewTee(&sentryCore, c)
})

logger = logger.WithOptions(withSentry).With(zap.String("test", "value"))

The problem is that if we use WrapCore like this in our middleware which gets the logger from main.go, then we re-wrap a core that was already wrapped:

// in middleware.go
withSentry := zap.WrapCore(func(alreadyWrappedOnce zapcore.Core) zapcore.Core {
	return zapcore.NewTee(&sentryCore, alreadyWrappedOnce)
})

But calling NewTee in main.go puts the loggers into multiCore which isn't exported.

What we want to do in the middleware:

• Clone our core, set the hub on the clone
• Keep the fields that were added before the middleware is created, meaning whatever logger.With was done in main.go

I think what we'd need for this is a way of disassembling the original multiCore, then clone one of the cores and update one of its fields. The only way I can see right now is to re-implement NewTee so it uses a publicly exported MultiCore, where we can loop through the cores and type assert them. Which all sounds pretty bad to be honest.

Maybe I can't see the forest for the trees and there's a much better solution? Big picture is we want some way of sending errors to sentry and having all the logger fields added to the Sentry scope for that error. So hooks won't work for this.

[abhinav]

Hey @cideM. Depending on what information you need in the middleware,
there are a couple ways to make your Sentry Core behave nicely here.

Minimal information

As a starting point: if the information you need is all present in a log
entry's metadata (the Entry), you can do this work in a Core.Check
implementation.

For background, the Core.Check method is expected to return a CheckedEntry
on which it has registered one or more other cores that are interested in
logging that entry.
There's nothing stopping the Sentry Core from putting a different instance
on the checked entry:

func (c *sentryCore) Check(ent zapcore.Entry, ce *zapcore.CheckedEntry) *zapcore.CheckedEntry {
    if ent.LoggerName != "default" {
        return ce.AddCore(ent, c.otherCore)
    }
    return ce.AddCore(ent, c)
}

Per-request information from middleware

If the information the Sentry Core needs must come from the middleware,
you can cheat a little:
have the middleware pass in a fake Field with the extra information
into the logger, and have the Sentry Core's With method pull it out.

For example, suppose that your middleware is extracting a SentryInfo worth of
information from the context and the request.

type SentryInfo struct {
    HubAddr string
    Tags    []string
}

func WithSentryInfo(info SentryInfo) zapcore.Field {
    return zapcore.Field{
        Key: "__sentryInfo",
        // Important to use SkipType here so that if this field accidentally
        // makes it to another Core, the system just ignores it.
        Type: zapcore.SkipType,
        Interface: info,
        // Note that ^this operation costs an allocation.
    }
}

The middleware will use the above with the Logger's With method:

logger = logger.With(WithSentryInfo(SentryInfo{...}))

In the Sentry Core's With method, you'll keep an eye out for a SentryInfo
passed in with that exact name and type.

func (c *sentryCore) With(fields []zapcore.Field) zapcore.Core {
    // In-place slice filtering.
    // See https://github.com/golang/go/wiki/SliceTricks#filtering-without-allocating.
    newFields := fields[:0]

    addr := c.addr
    tags := c.tags

    for _, f := range fields {
        if f.Key == "__sentryInfo" && f.Type == zapcore.SkipType {
            if info, ok := f.Interface.(SentryInfo); ok {
                addr = info.HubAddr
                tags = append(tags, info.Tags...)
                continue // don't keep this field
            }
        }
        newFields = append(newFields, f)
    }
    fields = newFields

    return &sentryCore{
        addr: addr,
        tags: tags,
        // ...whatever you do with the fields right now...
    }
}

Again, this is a bit of a hack, but it exploits the Interface field of
zap.Field to plumb information from the middleware to the Core.

Per-log-site information

This is super unlikely,
but if you have need of altering behavior on a per-log-site basis,
you can adapt the With thing above for any log field
by implementing the same filtering logic in Core.Write:

func (c *sentryCore) Write(ent zapcore.Entry, fields []zapcore.Field) error {
    newFields := fields[:0]
    addr := c.addr
    tags := c.tags
    for _, f := range fields {
        // ...same code as above...
    }
    fields = newFields

    client := c.client.ForAddr(addr)
    // ...
}

So any log site can do:

log.Info("foo", WithSentryInfo(override))

Hope this helps with your problem.

[cideM]

This is a phenomenal answer! I never thought of using With like this! I just tried it and it seems to work. Thank you so much for taking the time to write this elaborate reply.