Connection pool exhaustion from delivery thread serializing reports about bugsnag-ruby

[mclack]

Hi @evanlok

Apologies for the delay in response, and thanks for your patience.

In order for us to investigate this further, can you please confirm whether our understanding of what you are doing in the example is correct?

1. You're running Sidekiq supporting 2 concurrent jobs
2. You're enqueueing 10 jobs to run, passing in the reloaded Foo instance
3. The jobs are sleeping for 10 seconds, then raising a failure
4. When the failure is raised, BugSnag serializes the argument, which is a Foo
5. Serializing the argument calls to_s on it
6. This makes further network requests, and doesn’t return the connection to the pool

Please elaborate on anything here that may not be exactly correct.

[evanlok]

Yes, that is correct.

[clr182]

Hi @evanlok

Can you please elaborate on why you are making a database query in to_s ? We generally wouldn't recommend making a database call in such a way as to_s is a standard method in Ruby used to cast the thing you're looking at to a string representation. You wouldn't really expect this to do anything other than represent the in-memory object.

[evanlok]

The to_s method was querying for related configuration to determine the string output. We removed the database call from the method to resolve the issue but it's possible this can happen again in the future. It was quite difficult to debug initially so if there's a way bugsnag can prevent or warn when this occurs it would be helpful.

[mclack]

Hi @evanlok

Thanks for your patience on this.

We now have a task on our backlog to discuss and explore our options here when priorities allow. I can't currently provide an ETA on when this could be looked at, but we will make sure to post any further updates on this thread regarding future discussions or developments on this.