app_key is always YOUR_APP_KEY
I found the app_key in the request is always YOUR_APP_KEY.
I did set the app_key in the script TWICE.
Both are NOT working. Is there anything I missed?
I installed countly using docker.
Hello. Leaving it in the queue even with a failed request is such by design. There can sometimes be circumstances where a valid request fails sending it's data (server issue, wrong firewall config, etc).
The request won't be stuck in the queue forever. Request queue have a maximum size of 1000 requests. When that fills up, the oldest requets get's removed.
After debugging for some hours, I found what the issue is. The issue is that the first time I copy the script to my web app, which is react app and it's running. The default value of app_key is YOUR_APP_KEY, which is invalid, of course. But it is saved to queue in browser's localstorage and it's the first item in the queue. So when it's failed, it won't be removed from queue. And thus, it's stuck there forever. I believe it's a bug. It should be removed from queue, no matter is succeeded or not. So when I remove data, 'cly_queue' from localstorage, and it works.
The following code is from line 2055 in countly.js, line 2062 should be executed no matter what err is. Missing one action is not big deal. But stuck in the queue forever is not good.
How long does it take to fill up 1000 items in queue?
There is a scenario. A user creates a application in countly and set the app_key in app. All good.
After one day, he decides to remove the application and creates a new one which has new app_key. After he sets the new app_key, how long does he has to wait before it works again?
The fill up time depends on the app. Event creation frequency, usage of other features, etc.
If you create a new app, you can just leave the old app still alive for it to receive requests or you could write a server side plugin which rewrites the app key from the first app to the second app and this way redirect all requests.
Please sign in to leave a comment.