Data from retried REST calls are not passed forward

Currently seeing an issue with some of our workflows where a REST call defined with an (exponential) retry is passing data from the first failed attempt, instead of the successful retry.

  • REST block makes a unsuccessful call
  • wait period
  • REST call retried - is now successful
  • the next block receives null data and metadata relating to the first unsuccessful call.

Looking the the Run History shows the correct data being passed, but when the next block is executed, the data input from the REST block is null.

Anyone else seeing this or advice to fix? I've tried tweaking the retry parameters and redeploying but it's still happening. This is on a workflow that has been working successfully with retries for a long time.

+1 -- this is a big deal for us and causing production issues as of this week... somehow passing this along to Notion causes fields to be populated with [Object object]. Any ideas on a fix?

Hi @adelphes and @dennismagic, welcome to the forum! :wave:
I'm sorry this is happening to you. Have we tried testing the API in isolation? If we make a request from a TPA like Postman, is the data coming through as expected?

Could both of you share screenshots of your Workflows? We haven't found other reports of this issue, it might be something we can debug with you.

@dennismagic, for your case, we might need to key into the right nested key to retrieve the value.

You can also join us during Office Hours, we would love to take a look at what is going on.

Thanks @Paulo .
Here's a screenshot of our updated workflow and the logs from a run showing the problem. To workaround this issue, we now need to create 2 REST API blocks - the first performs retried API calls until it succeeds and the second calls the same API again (which usually won't need any retries because the API call from the previous block succeeded).
The workflow is triggered by a webhook.

To check if we are still seeing the issue, we have an additional checkIfDataPassedCorrectly block which just tests the data from the getOrder1 block and prints the output.


This is definitely odd behavior. Were you able to make the request outside of Retool? Since we are not able to reproduce it, I wonder if it may be an issue with the API endpoint. On the other hand, your workaround sounds great!