In this meeting, the State Changers discussed debugging challenges related to API calls and dealing with inconsistent return values. They discussed their experiences with "Zano" and how sometimes the data returned is completely blank, even though they know that the data is supposed to be present. The issue might be related to the service provider throttling their APIs, or it might be due to other technical issues on the provider's end.
The discussion then focused around a possible solution - retrying failed requests. They discussed the importance of checking the status code from a response. A status of zero indicates that there's no response from the server, while a status of 200 would mean success. However, any other status usually points to some kind of problem. The participants suggested flipping the model from retrying on failure to continuing until success. They proposed a method where the API call is positioned within a 'for' loop, that makes a certain number of attempts (five in the given example) to make the call. As soon as a successful response (status of 200) is received, the loop is broken, preventing unnecessary repeated calls. If after 5 attempts a successful response is not received, the system could be set up to stop trying or signal an error. The participants also mentioned the use of sleep function between attempts to allow for any potential rate limiting or other issues on the provider's end to resolve themselves. They touched on the potential to use a multiplier to incrementally increase the sleep time with each attempt, although they noted that a basic approach might be sufficient in many use cases. This meeting would be useful for anyone dealing with debugging API calls, handling unsuccessful or inconsistent responses, and implementing retry mechanisms.
(Source: State Change Office Hours 6/15 )
