One bad request chokes the whole request queue.
The way Countly handles bad requests is that it:
1. Leaves them on the queue
2. Stops processing the queue
The result of this is that as soon as one bad request makes it to the queue (example: an invalid API key or checksum), the entire queue is now dead. Fixing the underlying issue causes good requests to get queued, but the bad requests at the top of the queue prevent Countly from ever sending the good requests to the server. Consequently, there is no way to recover and since the queue is persisted, these devices will now go offline forever.
The only thing that can be done is to manually invoke flushQueues. Unfortunately, there is no way for the application to know when it should be doing this, since it has no insight into the queue and its state. This should absolutely be handled internally by the Countly SDK.