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.
Comments
Hello Ihunath,
1. SDK does not use API_key but rather app key
2. app key should not change inside single app, and even if it changes, as long as server accepts those apps there is no problem, the only problem is when app key is incorrect and server does not have app with that key, which usually is the problem while developing/integrating SDK and can be fixed by app reset or clearing storage
3. SDK does not stop processing requests at all, when max request lifetime is reached (upon reaching maximal queue storage) the older request (which is incorrect one) will be removed, allowing all other valid requests to be processed correctly
4. Check out this link for more info and example on request storage and queuing.
Let me know if you have further questions, thanks.
Please sign in to leave a comment.