Workflows : multiple bugs, including branch blocks failing

Workflows
1

Hello!
I've seen a lot of topics that describe the problem with referring startTrigger.data - I've got it also.

I also have a problem that now branch blocks do not run anymore with Internal Server Error

image
image1676×632 71.7 KB

What's wrong?

1 Like
2

Hi @dsitnik - welcome to the forums.

I was having this issue too, but it seems to have been resolved for me. I just tried creating a branched workflow which worked fine for me (granted it was nothing fancy, but it did reference the startTrigger and a query to a DB). Have you tried closing out the workflow and re-opening it? Sorry, I know that is an annoying answer, but humor me...

1 Like
3

I still experience this

4

it might just be checkVer blocking the connecting lines or something, but it looks like you have the input for the checkAction block connected to the webhookReturn1 input... which would mean both blocks are 100% unreachable. workflow execution would either silently finish after checkView, timeout after the max workflow execution time is reached(run-time error) or if there is another block connected to one of those inputs, it could make compile-time/linter errors

5

its not possible to connect inputs :wink:

1 Like
6

Hi @dsitnik :wave:

I also was not able to reproduce this bug. Have you tried making a new workflow? Not the ideal solution, but could unblock you.

Are you on cloud?

7

just to add a couple things to @AbbeyHernandez's suggestion/question that might help us find the source of this:

  • on the Inputs window for the branch blocks, are the previous blocks showing up w values (not grayed out)? sometimes I catch blocks not realizing they're connecting to things when they are... I don't think I normally get that error you're seeing but :man_shrugging: maybe we can get lucky here :beers:
  • try using the drop down context to Switch block to JS Block(or make new blocks i guess) :
    - if(getMacReport.data[0].report_version === startTrigger.data.report_variant){ return true; } else{ throw Error("checkVer error"); }
    - i'd suggest adding a Global Error Handler. you can use { error: workflowContext.currentRun.error } for the code.
  • it's just a guess, but a dangling pointer of some sort that missed garbage collection might cause an internal error? i think it's somewhat equiv to 'unidentified' in js. did the problem start after renaming the block or were these some other type of block originally and the Switch block feature was used to turn them into branch blocks?
  • can you try using 'duplicate block' to make a copy of the 4 blocks:
    • leave the original block there after you duplicate each, don't delete them.
    • disconnect startTrigger -> getMacReport and re-connect the startTrigger to the copy:
    startTrigger -> getMacReport_copy -> 
    checkVer_copy::if -> checkAction_coppy
    checkVer_copy::else -> webhookReturn5_copy
    • the general idea is like the last one in that if the list of generated functions from the framework is corrupted, deleting blocks and remaking them might not cleanup the code properly (picture deleting all the blocks, but the list of blocks retool keeps behind the scenes isn't empty and doesn't match what you see... recreating the block or making a new one now could give an opportunity for an array out-of-bounds error or some weird "type cast" error in js). so instead, we accept that section of memory is corrupted and start new code generation after this section completely skipping whatever might be messed up.
  • try the same thing above, but with creating new blocks instead of using duplicate.
1 Like