Countly reqeusts failed when changing to incorrrect then to correct App Key about countly-sdk-web HOT 10 CLOSED

You can either:

• clear the local storage, or
• call Countly._internals.clearQueue() or
• use another app namespace, or
• wait for the queue to reach the limit and older requests will be removed

from countly-sdk-web.

Is there a way i can capture the error response inside the app. so that i can go ahead and clear the queue.
I don't want to clear the queue because i may loose logs from previous session.

from countly-sdk-web.

This is not something that is likely to happen in production, so no need to try to automate it (how many times you would change app_key in production)
and even if it did, if app_key changes then you can just deploy update using new namespace so it has clear storage.

or another workaround is to create another app in countly with incorrect app key that you had and let it consume the data

from countly-sdk-web.

If this ever does happen in production, you could really be in trouble.

Would it not make sense for the SDK to be robust enough to recognize this situation and deal with it gracefully? A 400 response indicates that the request that was made should not be repeated and be expected to succeed. However, by the status code alone, you won't know why. But if the server response would include some JSON saying why it failed, in this case a bad app key, shouldn't that be enough to invalidate all the events in the queue that carry that app key?

from countly-sdk-web.

We cannot make that assumption on behalf of clients
maybe they accidentally changed app_key and will change it back and don't want to lose queued data
If something is deleted it should be explicitly deleted by the client's actions, not SDK (at least those are the general guidelines)

from countly-sdk-web.

However I have another idea for a potential solution, but it is on more larger scale (changing the SDK development guide flow, meaning it should propagate to all SDKs not just web SDK) and can't figure out proper migration yet
but it would be something around having separate namespace storages based on app_key
so if app_key is different it has completely different new clean storage, and older app_key storage remains intact in case it will be used again.

from countly-sdk-web.

That would be idle.
I am reporting the problem because, we have faced this issue.
We have deployed the app with incorrect app key then realized the requests are failing with 400 because of incorrect app key.
Correcting the app key has no effect because sdk was trying to use old app key, in my case the queue is no emptied even after an hour.

from countly-sdk-web.

as I said, the current fix would be redeploying app with the new namespace for storage
http://countly.github.io/countly-sdk-web/Countly.html#.init

from countly-sdk-web.

Or if it is a completely new and clean app on Countly side, simply changing app_key to the one you used would also be an option

from countly-sdk-web.

I have also just spent a day trying to work out what was happening with this same issue. This was in development, but to find the answer I ended up having to debug Countly Code.

An improvement would be for sendXmlHttpRequest ->

      xhr.onreadystatechange = function () {
            if (this.readyState === 4 && this.status >= 200 && this.status < 300) {
                if (typeof callback === 'function') { callback(false, params, this.responseText); }
            } else if (this.readyState === 4) {
                log("Failed Server XML HTTP request", this.status);
                if (typeof callback === "function") { callback(true, params); }
            }
        };

To return this.status to the call back.

        xhr.onreadystatechange = function () {
            if (this.readyState === 4 && this.status >= 200 && this.status < 300) {
                if (typeof callback === 'function') { callback(false, params, this.responseText); }
            } else if (this.readyState === 4) {
                log("Failed Server XML HTTP request", this.status);
                if (typeof callback === "function") { callback(true, params,this.status); }
            }
        };

Then in the callback:

       sendXmlHttpRequest(Countly.url + apiPath, params, function(err, params, response){
            console.log("Request Finished", params, err, response);
            if (err) {
				if(response==400){
					console.log("jhop Request failed, ignore it")
					//remove first item from queue
					requestQueue.shift();
				} else {
					failTimeout = getTimestamp() + failTimeoutAmount;
				}
            }

This means that if the server returns 400 (server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). Then the the rest of the messages are not blocked and lost, due to something they are never likely to recover from. One incorrect message on the queue means the rest of the data is unrecoverable. the above approach means the rest of the data on the queue can be received.

You could also configure a setting to turn this feature off if that is required.

from countly-sdk-web.