Workflows: Bug with Sendgrid iterating over data from DB


I am having a workflow that should access my connected DB and send out an email via a loop to Sendgrid. The have done this before, but there seems to be something off now. Whenever I pass the value to field, the UI shows the correct data, but when the workflow is executed, nothing gets passed into it.

This is how it looks in the UI:

And when I execute the workflow and look at the request data sent to Sendgrid I see this

As I said, I am accessing Sendgrid via a loop, to iterate over every row returned from the DB, this is how I have done it in a previous workflow, but this time its not working as expected. The same seems to happen for other fields whenever trying to access the variable {{value}}.

Is this a bug? Or am I doing anything wrong?

Hi @phi thanks for reaching out! I am trying to reproduce this, but I'm not coming across the same issue :thinking:

When you execute the workflow, do you mean that you are cliking this button in the top right of the workflows editor?

Can we see a screenshot of the loop?

What do the logs say for the input to this block?

Hey @Tess!
Thanks for getting back!

As to your first question, it does not matter how I execute, e.g. running the complete workflow or the email sending block separately, I do get the same results. The error, that I am getting is a 400 from Sendgrid iteself, because the POST request does not contain the data. This is also what I do see in the logs.

The input to the loop does seem correct, it just contains the data of the SQL query that is run before. Do I need to access these values differently, as mentioned using {{value}} right now.

Here is a screenshot of the complete block, including logs, please note that the error given back also corresponds with the input sent to Sendgrid:

Let me know if you need more info!

Hi @phi,

Thanks for the screenshot.

Can we see what value is evaluating to? It should be on the inputs tab of this block. Here's an example of a working query that I'm using to test:

For the dynamic_template_data, is {{value}} evaluating to an object:

Do you also have the content & template_id sections filled out?

Just replying here that I've been having the same issue and there has been no movement on my post that is a couple weeks old :frowning:

Hi there! We are catching up on a bit of a backlog, so apologies for the delay!

Can we see a screenshot of your Sendgrid block's inputs? I haven't been able to reproduce this issue yet :disappointed:

Are you both seeing this issue on Cloud, or are you using Retool on-premise?

If you're not sure, you can click the ? icon on the Retool home page to find the version number:

I am using Retool cloud.

I am using cloud as well. @Tess all variables are filled out correctly and if I change to the UI view I see that everything gets evaluated correctly, they just not seem to be forwarded to the POST request of the Sendgrid endpoint.

Hi @phi Where are you seeing that the variables are filled out correctly? Apologies, but can you clarify what you mean by switching to the UI view?

@Tess sorry for the confusion. By UI view, I meant that the current Sendgrid block the user can either add the data as JSON as in your example or fill out form fields. I validated that the data is the same by hovering over the data in the from field (see the first screenshot of my initial post for reference). Let me know if this is the wrong way of validating :slight_smile:

I am having the same issue when calling the REST API for PayPal invoicing. I see the values 'resolve' inside the little green window, but when the API call is actually made those values are not passed.

For example, in the workflow I see the correct values populating in the raw JSON I am constructing, but when the API call is made to PayPal to POST, those values are missing.

If I copied the JSON from the green window and pasted into PostMan, the API call works. It's just that Retool is eating the values somehow. It all seems related to the other issues we have been posting about regarding loops and {{value}} not working.

@Jessica_D thanks, exactly! Thanks for the elaborate answer! I do get exactly the same behaviour.

@Tess if I understood you correctly, you cannot reproduce this error, right? Can you share which browser you are using? I really need to get my new feature out asap and would appreciate any help!

Hi @Jessica_D,

Can you also share a screenshot of the inputs section of the block? That will help us to investigate where there is a potential bug.


Can you also share the exact date & time of one of the runs that has this issue?

@phi I am testing this on Chrome and haven't run into any issues yet :disappointed:

This issue happens all the time, there has never been an instance where it worked yet for me.

I don't have the workflow set up the way I showed you earlier (where it was within one workflow making the API call). I changed it back to how I prefer, one workflow invoking another to keep things cleaner, so I don't have the input screenshot for you. But I did verify the inputs are setup correctly when I was testing. Any chance you can just go in my workflow and test it out? Everything in staging is connected to a sandbox environment so you won't break anything.

Well here is a screenshot of what I'm seeing now. Everything is showing as null even though there are values in the inputs section.

I sort of figured out what is happening in the previous screenshot I shared where the green window shows null even though there are values in the input. If there is one null value in the input, then the entire thing just shows null (seems like another bug for you guys to look at.. )

In my next data set, I am populating all the values, so the green window is now showing values again but the values still do not get passed down to workflow #2 or an API called from workflow #1 (when I previously had it configured that way).

Is there any way I can jump on a call with Retool support to screen share or walk through this very critical but broken functionality?

Hi @Jessica_D Thank you for the update! I'll keep looking into this today, but I wanted to check in. We're not able to schedule 1:1 calls, but we'd love to take a look if you can join office hours today at 11 am pst.

Yes, I'll be there. I have a hard stop at 11:40 PST so hope we can hit the ground running right away. I have a number of test workflows I can show with differing results to try and pin down this issue.

Hi @Jessica_D,

Our Workflows team has been working on this issue, but we still don't have a consistent example of this happening which means it'll take longer to get to a fix :disappointed:

We were briefly able to reproduce this issue, but deleting and re-creating the block resolved it. Have you tried this? @phi can you also try deleting and re-creating your block?

We're wondering if you can show the exact steps taken to get a workflow into this state? I tried to reproduce it in the exports of your workflows, but they're all working fine on my side :thinking:

Can you also try running the workflow in an incognito window? It seems very unlikely in this case, but it always helps to confirm the issue happens in a private window that doesn't have any browser extensions.

Apologies for the added work on your side :confused: hopefully, we can narrow down where the bug is asap!