Workflows: Bug with Sendgrid iterating over data from DB

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.

image

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!

@Tess I have tried to delete and re-create a block and had the same issue. I've also been able to create 10 different workflows from scratch that have the same issue.

Incognito mode made no difference.

I've also tried to use an API call to a web hook to call the downstream workflow and I got a similar error to the one I showed you last Thursday at office hours when I try to just do everything in one workflow.

Error evaluating callDoStuffRest_lambda: Resource 'JavascriptQuery' has either been renamed, deleted, or does not exist in staging. Please select a different resource.

Hey @Tess,
sorry for the late response. I have been travelling the past days.
I just spun up a complete new workflow doing the exact same things. It seems that the parsing of the loop now works correctly. Not sure what the cause was, but this is working. Strangely though, I realized that passing in hard coded values now shows the exact same behaviour as before. For example, I am passing for {"from": "example@example.com, ...} and the output shows an empty object. I was able to work around this, but I am confident that this will soon come up at another end.

Hi @phi Thanks for letting us know! I'm glad you're able to move forward, but we definitely still want to resolve this

@Jessica_D Thanks for letting me know :disappointed: What OS and version # of Chrome are you using?

I'm also going to send you a DM about stepping in to your account if that's still okay with you

Our team is still investigating this bug & I'll post here with any updates. For the time being, we seem to have found a temporary workaround, as described here