Protected workflow calling another protected workflow is failing on feature branch

💬 Workflows
,
1

I have 2 protected workflows: ParentWF and ChildWF. Both workflows are on the same git feature branch, MyBranch. ParentWF triggers ChildWF in a loop block loopChildWF.

When I manually trigger ParentWF, it fails in the loop block while calling ChildWF.

Error from ParentWF log:

...
Error evaluating loopChildWF (iteration 3): Error fetching data for loopChildWF
 response: {"error":true,"message":"Internal server error"}
 error: "undefined" is not valid JSON
...

The loops runs 5 times, and the above error message is there for each iteration. Why is this happening? I have used this pattern extensively, where I have multiple protected workflows all on the same git feature branch, where some of the workflows call the others. I haven’t used it in the last month or two, and all of a sudden, starting last week, the above error started happening.

Some data points

  • No changes have been made on any protected workflow. The branch is completely fresh and clean.
  • If both workflows were on main, everything runs perfectly.
  • If ParentWF is on the feature branch MyBranch, and ChildWF is not on the feature branch (nor has it ever been on MyBranch), running ParentWF works great. Within a minute or two of switching ChildWF from main to MyBranch, the above error starts occurring. Once ChildWF has been switched from main to MyBranch, running ParentWF on MyBranch fails every time, even if you switch ChildWF back to main .
  • When both ParentWF and ChildWF are on MyBranch, and you look at Run History, you’ll see the runs for ParentWF with the errors in the logs, but you’ll never see any runs for ChildWF.

I definitely think this is a bug for a couple of reasons

  • It used to work, and I’ve used it extensively.
  • Logically it makes sense that if 2 workflows are on the same git feature branch, then one calling the other, would call the version of the workflow that’s on the same feature branch.
2

Summary

Two protected workflows (ParentWF and ChildWF) live on the same git feature branch, where ParentWF triggers ChildWF inside a loop block. Since last week, that loop fails on every iteration with an 'Internal server error' / '"undefined" is not valid JSON', ChildWF never shows any runs in Run History, and the failure only occurs once ChildWF is moved onto the feature branch (both on main works fine).

AI Response

This pattern of symptoms points to a source-control state issue on the feature-branch copy of the workflow rather than a problem with the block logic itself. A closely matching community report shows a protected workflow that consistently returns 'Internal server error' only on a specific branch, works fine on other branches, and shows no workflow runs on the affected branch — and Retool staff identified the likely cause as the source-control state of the workflow as a whole. The suggested next step there was to create a fresh branch and re-check out the workflow, since the corrupted branch state persists even after switching the child back to main. It's also worth confirming, per the Run Workflow block docs, that ChildWF contains a Response block and is referenced/deployed correctly, as a child run behaves like a webhook-triggered workflow and must return data to the parent. Recreating the feature branch is the most consistent workaround reported for this branch-scoped internal error.

Sources

:bookmark: Retool Workflow just shows 'Internal Server Error' for everything and anything on specific branch
A near-identical report of a protected workflow returning 'Internal server error' only on one source-control branch (works on others, no runs recorded), where staff attributed it to the workflow's source-control state and suggested creating a new branch.
:bookmark: Run another workflow with the Workflow block | Retool Docs
Documents how the Workflow block runs a child workflow like a webhook-triggered run and requires a Response block to return data, useful for verifying ChildWF is configured to return correctly.

The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a :heart:, :+1:, or :-1:. Or by marking this post as the "Solution"! Let us know if you have any feedback here. :rocket:

1 Like
3

A few additional troubleshooting steps I took:

  • I have create a new git feature branch and the issue still exists. In fact, I have tried this on a number of feature branches.
  • I have tested this with a completely different set of protected workflows, and issue still exists.
  • I have duplicated a set of simple workflows, protected them, and issue still exists.
1 Like
4

This sounds like a branch-resolution issue rather than a problem with the loop itself, especially since ChildWF never appears in Run History. The fact that it works on main but fails once both workflows are moved to the feature branch seems like a strong clue.

5

I ended up filing a support ticket with Retool and they have identified the bug and it’s being worked on. From what they said, it would be out in a release happening this week.

1 Like
6

Hey @LindaEdwors welcome to the Community! :partying_face:

Quick update for everyone here! @lkiss, you've got it exactly right. The fix for this is deploying to production right now, and I'll circle back here to confirm as soon as it's fully rolled out.

Appreciate everyone's patience on this one! :folded_hands:

1 Like
7

Hey @lkiss and @LindaEdwors good news, the fix is now live in production on Retool Cloud 4.47.0. Give it a try and let me know if everything's working as expected on your end!

1 Like
8

Hello again @lkiss and @LindaEdwors I'm going to go ahead and mark the fix confirmation above as the solution for visibility so others can see the fix easily. Please do let me know if anything isn't working as expected on your end! :folded_hands: