Goroutine kicked off at import time

[NeilLuno]

Describe the bug

At https://github.com/bugsnag/bugsnag-go/blob/master/v2/notifier.go#L7, newPublisher kicks off a goroutine at import time. This means that just importing github.com/bugsnag/bugsnag-go/v2 results in a goroutine. As far as I can tell, there's no way to terminate the goroutine.

While this isn't a problem for us from a performance point of view, it does mean that when using go.uber.org/goleak, we have to add an exception for bugsnag-go. It's not the end of the world, but it's a nuisance.

Steps to reproduce

See example program below.

Environment

• Bugsnag Go version: v2.5.0
• Go version: go version go1.22.5 darwin/arm64
• Integration framework version:
  • Martini:
  • Negroni:
  • net/http:
  • Revel:
  • Other:

Example Repo

• [ ] Create a minimal repository that can reproduce the issue
• [ ] Link to it here:

Example code snippet

// test.go
package main

import (
    "fmt"

    _ "github.com/bugsnag/bugsnag-go/v2"
    "go.uber.org/goleak"
)

func main() {
    err := goleak.Find()
    fmt.Println(err) // Should print nil. Prints "found unexpected goroutines:..."
}

Error messages:

``` ```

[mclack]

Hi @NeilLuno

We've discussed this, and as a result we have added a task to our backlog to see whether we can start this goroutine later. I don't currently have an ETA on when this will be properly looked into, but we will make sure to post any updates on this thread.

For additional context, the behaviour for the asynchronous sending of events to BugSnag changed in the v2.5.0 release of bugsnag-go. Instead of previously where a goroutine would be triggered for every event report, a single goroutine is now started by BugSnag, and this acts as a queue for events to be sent from.

[NeilLuno]

Hi @mclack. I really appreciate the response. Agree that one goroutine is better than many. We've managed to find a workaround in the meantime.