Your client documentation, as well as your implementation of the auto_pagination in the Client#paginate method both rely on usage of Bugsnag::Api::Client#last_response/@last_response. Because folks will often be using the singleton instance of the client via Bugsnag::Api.client, this makes it very likely that there will be collisions when using this api in a multi-threaded environment (like Sidekiq), not exclusively, but especially if configured for auto_pagination.
I would suggest that you remove #last_response from the Client as a class attribute as well the public method, and in your auto_paginate implementation, you simply using a locally scoped variable instead.
If folks want to store the last_response in their own usage of the library, they can store it themselves in a local variable.
Hi @BobbyMcWho - thanks for raising this. We've updated the docs for our Ruby API Client to clarify that the static API client may not work as expected in multi-threaded environments.
Your client documentation, as well as your implementation of the auto_pagination in the
Client#paginate
method both rely on usage ofBugsnag::Api::Client#last_response
/@last_response
. Because folks will often be using the singleton instance of the client viaBugsnag::Api.client
, this makes it very likely that there will be collisions when using this api in a multi-threaded environment (like Sidekiq), not exclusively, but especially if configured for auto_pagination.I would suggest that you remove
#last_response
from the Client as a class attribute as well the public method, and in your auto_paginate implementation, you simply using a locally scoped variable instead.If folks want to store the last_response in their own usage of the library, they can store it themselves in a local variable.