Indefinite wait in Send API Request v4.vi

[Kelvador]

In the Send API Request v4.vi located in the AWS Toolkit ->Core -> HTTP Request folder, in the GET case there is a -1 wired to the timeout terminal which causes this VI to wait indefinitely (see attached screenshot).  I am using the AWS toolkit to report and alter Thing Shadow states and I have run into instances where my program halts at this get case due to the -1 timeout; at that point, I have to force quit the program and restart everything.  To resolve this, I changed the -1 to 3000 ms and the program has worked fine since then.  Has anyone else run into this issue?  I'm curious if this is a bug or if there are specific reasons to leave this wired as an indefinite timeout.

[Darren]

There are some GET requests that take a really long time, particularly when working with S3 and large files are involved. That's why the GET request has no timeout, while all the others (PUT, POST, DELETE, HEAD) use the default timeout. I'm curious why your request is taking so long. If it times out, doesn't your code error out? What is the benefit to your use case if the request times out and the GET request you're trying to send doesn't return anything?

[Kelvador]

Yes, if the GET times out then I receive an error and handle it appropriately.  I am not sure why the GET request takes so long sometimes; I am performing simple desired and reported Thing shadow states and I could not find any pattern as to when the long GETs happened.  It is good to know that the -1 on the timeout is intentional though as now I can dig in a little deeper as to why I am experiencing this problem.  My goal is to use the toolkit without making my own modifications to the VIs to get things to work.

[Darren]

One potential area of improvement for a future version of the toolkit, which would be very easy to implement, would be for us to expose timeout values for each HTTP method on property nodes of the class wire of the API. They would default to their current values (-1 for GET, 10000 ms for the other methods), but you could easily use a property node to modify the timeout before/after a particular API call for special situations.