My goal: So I want to upload a csv and then run every item in that file through 2 API calls. I need the response from the first API before I call the next query
Issue: When the API returns a 400, it always returns a undefined. It's not an error but undefined.
Steps I've taken to troubleshoot:
using async
for (const row of data_from_table) {
let apiResponseData = await provision_api.trigger({
additionalScope: {
id: row.id,
extra_data_1: row.extra_data_1,
}
});
// when we have a 400 returned from the API, apiResponseData is undefined.
// therefore this is an error
await save.trigger({
additionalScope: {
id: row.id
timestamp: new Date().toISOString(),
http_status_code: apiResponseData.http_status
}
});
}
Promise.all
// map through every row of a csv file and call an API
return Promise.all(
data.map((row) => {
return provision_api.trigger({
additionalScope: {
id: row.id,
extra_data_1: row.extra_data_1,
}
});
}),
).then((results) => {
// results is undefined
console.log(results);
return results;
}).catch(error => {
// never hit
console.log('this');
});
Additional info: (Cloud or Self-hosted, Screenshots)
I've tried changing the failure conditions, still only getting undefined.
This sounds like some logic that might be better handled in workflows, where you can use loop blocks to make a series of API calls, have all the results stored as either undefined or some data type, then move on to the next step where you can make a number of decisions about how to pass the data into the second API call.
You could have an if block or a filtering block to remove the undefined results, you could also map over the data that was used in the call and make on object if you want to keep a reference to which calls returned undefined.
Then you can pass the data you want to another loop block to make the second set of API calls. The handling of undefined in queries in the app can be somewhat limited when making large batches of calls and is better suited for making single calls instead of using JS and Promise.all to run concurrent async queries/API requests.
Regardless of whether this could or should be done in a workflow, I think the question is still a valid one – how does one get access to the error, via apiResponseData? Clearly the global resource query has it. Shouldn’t that same error information be contained within apiResponseData ?
Hey @lkiss - error handling within Retool is definitely a bit different. As you've already noticed, unsuccessful query triggers don't actually return anything and additionally aren't caught by a conventional catch block. Instead, you'll want to utilize an onFailure handler:
