Automatic retry when we get re-tryable responses code

[tom-aspireleaders]

When an end point produces a result code that is retry-able, for example the following seem like good candidates.
408 Request Timeout
503 Service Unavailable
504 Gateway Time out

It would be great if API connect would wait a time out period and retry. And that that retry count and delay were set-able paramaters. The backoffs should generally be exponential in nature.

The default behavior of API connect should be unchanged and not try to re-try as the current API connect is designed. Explicit paramaters should have to be set in order for this to take effect.

[alexbourret]

Hi @tom-aspireleaders ! Good idea, we will try to implement this in the next version...

[tom-aspireleaders]

Thanks.

I did some research. When thinking about doing this on my own. There are a few Python libraries out there that implement this. I’ve not done enough research to tell if I trust those or think they’re a good idea.

If you would like me to test a version let me know.

[alexbourret]

Hi @tom-aspireleaders ! There is a V1.4.3-beta.1 here that implements a configurable retry on several http errors. Let me know what you think...

[tom-aspireleaders]

That was way faster than I expected. Thank you.

Is this expected to be reliable enough to use with a production workload?

Or do I need to use this with an a separate instance?

[alexbourret]

It has not been through the formal review process, so I would keep it for tests on a separate instance at this stage...

[tom-aspireleaders]

Ok, I did an install on the instance of DSS running on my mac. First time I did not record the error message. Sorry about that. But there was a reference to scipy in an error message when I tryed to open the dataset.

I'm trying to update the plugging's python code env. First attempt on 3.11 cause some sort of error, this may be a local configuration thing. I've downgraded to 3.10 and the code environment seems to have built out.

Got the same error message again.

Because there is potential for Security issues. I'm not going share the full log here. I can do that through the Dataiku tech support system. Here is a Claude summary of the error message.

API Connect plugin v1.4.3 — 'NoneType' object has no attribute 'status_code' on the second pagination call

Environment: DSS 14.7.2 (macOS local install), API Connect plugin v1.4.3, REST connector dataset, pagination_type: offset, raw_output: true.

Symptom: Page 1 of an offset-paginated GET succeeds (1000 rows). Page 2 fails immediately — the plugin's own error handler raises AttributeError because response is None, which masks whatever the real failure was. Note the timestamps: the failure is in the same millisecond as the "Accessing endpoint" log for call #2, so no HTTP round trip took place (call #1 took ~9 s).

Two things worth noting called out by Claude from the error logs.

1. rest_api_client.request() reaches response.status_code with response is None. There is no guard, so the underlying exception is discarded and replaced with an unhelpful AttributeError. A None check (or re-raising the original exception) would surface the real cause.
2. The skip parameter changes type between calls: ['0'] (list of str, from the query-string template) on call Generic rest API plugin #1, then a bare int 1000 (from update_next_page_offset) on call Removing endpoint preset :( #2. Possibly unrelated, but it is the one thing that differs between the working call and the failing one.

When I reverted to 1.4.2 things went back to working OK.

The UI worked OK. Initially it was a bit confusing what I was supposed to do for selecting the re-tryable error codes. I figured it out fairly quickly. But it was a bit confusing.

It also appears that the recipes JSON setup retains the retry-able codes list even when you turn off the retry feature.

Hope this helps. Let me know what you'd like me to test next.