SGL

Hi Greg Katechis

Sorry to keep bugging you, but I may not have been clear.

You and your collegue are mistaken about the endless loop. The structure of the code goes like this:

while(ret = "retry"){
        ret = await client.request(settings).then(
            function(data) { // NO ERROR -- here there is no error 429 or otherwise, so carry on
                    return "Exit the Loop"
            },
            async function(response) { // ERROR TRAP -- for 429 and other both return "retry"
                if (response.status === 429) {
                    return "retry"
                }
                else
                {
                    return "retry"
                }            
            },
        );

So, the code only returns "retry" if there is an error -- otherwise it exits the while loop. My problem is that the console is sometimes showing 429 errors and the code seems to halt, but neither the "no error" code nor the error trap code seem to fire (I can see this because the console.log messages in the original code in my first post are not showing.)

I hope I can fix this issue soon as I am on a time schedule to complete my app.

Just to add. The reason that the error trap is async is because it needs to 'await' the sleep function. The idea is that a 429 error means there should be a pause before trying the action again. The pause gets longer after repeated 429 errors -- until there are no 429 errors. But, as I say, the problem is the error trap is apparently not firing off.

Hi Greg Katechis

Just saw your reply. The code does not usually go into an endless loop. Mostly it works fine. If there are no errors then "ret" returns "json.job_status.url;" and the execution continues (please re-examine the code).

The problem occurs when there is a 429 error. I would expect the code to either print "429 error closing tickets. Waiting... " to the console, or "retry" to the console. But neither is happening.

The code I have is based on the following kind of template (the first function executes when no error occurs, and the second executes on error):

client.request('/api/v2/tickets.json').then(  function(tickets) {    console.log(tickets);  },  function(response) {    console.error(response.responseText);  }

Looking at my code again, I think the locking up is likely due to the error function being async, and it is waiting for execution of something elsewhere that never occurs (?) before it continues. The reason I made it async was so that the code would not continue before the exponential back-off strategy had completed

Hi,

I have a function that closes tickets using the API. I have written an error trap for 429 errors. Mostly the function runs fine without triggering 429 errors (i.e. there is no throttling issue). However, sometimes multiple 429 errors occur in the console and it seems to go into an infinite loop.

I've put the function below. Note that the console.log does not seem to fire -- meaning the error trap does not catch the 429 error.

Can anyone advise?

async function closeTickets(arrayTicketIDs)
{
    // close tickets
    API = "/api/v2/tickets/update_many.json?ids=" + arrayTicketIDs;
    myURL = encodeURI(API); 
    var settings = {
        type: 'PUT',
        url: myURL,
        autoRetry: false,
        dataType: 'json',
        data:{
            "ticket": {    "status": "closed"  }
        }
    };
    ret = "retry";
    let W = 0; // Exponential backoff strategy -- for 429 error, we want to wait 2^W seconds, where W increases by 1 for each 429 error
    let retryAfter = 0;
    while(ret = "retry"){
        ret = await client.request(settings).then(
            function(data) {
                W = 0; // reset wait time
                var json = getJSONInfo2(data);
                return json.job_status.url;                           
            },
            async function(response) {
                if (response.status === 429) {
                    retryAfter = 1000 * Math.pow(2, W);
                    console.log("429 error closing tickets. Waiting... ",retryAfter)
                    W = W + 1; //exponential increase in wait time.
                    await sleep(retryAfter)
                    return "retry"
                }
                else
                {
                    showError(response);
                    console.log("retry")
                    return "retry"
                }            
            },
        );
    }

    return ret;
}

Hi Ahmed Zaid

Thanks very much for this.

Simon.

Hi Ahmed Zaid

Thanks for the response. Could you tell me how to do this in Javascript?

Hello,

I have submitted an app to the marketplace but there are some blockers. One of which is

• Seen "setInterval" but not "app.willDestroy"

Can anyone advise how to implement this in my app.

I should mention that there is a post from 2021 that says app.willDestroy is deprecated (see link below). But I have only just received this feedback which mentions the missing app.willDestroy.

Thanks,

Simon.

Thread from 2021:

https://support.zendesk.com/hc/en-us/community/posts/4408860806554-Seen-setTimeout-but-not-app-willDestroy-I-couldn-t-find-an-event-called-willDestroy-in-the-ZAF-documentation-

Hi Greg Katechis

C.C. Paulo Filho

I've done some load testing on the API, which produced many 'throttling' warning messages, but no 429 errors in the main (I did get a single one at one point, but couldn't reproduce). I feel the throttling is something beyond my control to catch in the code, so I think that the 429 error trap is the best I can do.

I have also modified the error trap (I think either the syntax was wrong for returning the "retry-after" value, or it may not return this for all API calls). The new error trap implements an exponential back-off strategy. Here is a snippet of the code:

if (response.status === 429) {
                    retryAfter = 1000 * Math.pow(2, W);
                    W = W + 1; //exponential increase in wait time.
                    await sleep(retryAfter)
                    return "retry"
}

I should note that I seem to be getting fewer throttling messages in my app since making changes, but this may or may not be due to other factors. Under certain circumstances I may get as many as previously (?).

As far as I'm concerned, we can close this thread. I'm going to mark this post as 'answer'.

Thanks, Simon.

Hi Greg Katechis

Have you managed to look at my throttling issue yet?

Thanks,

Simon.

Hi, I'm glad my comment was helpful to you.