Conditional Failing Silently

[lue3099]

Hello,

I have a workflow that is failing silently at a point with two conditionals.
These conditions just check resolution and sort to two folders.

conditional-screenshot.png (119.6 KiB) Viewed 1598 times

The way Im thinking it should work (correct me if im wrong).
Is the sd-testFile.mp4 should fail the top conditional then succeed on the bottom one as the test file has "%i_height%" of 240
But it doesn't. Why?

The workflow is a recreation of a much larger workflow so the one attached is just used to recreate the issue.

Here is the sceencap of the issue.

Here are test files information:

MediaInfo_SD-testFile.txt

(3.13 KiB) Downloaded 89 times

MediaInfo_HD-testFile.txt

(3.5 KiB) Downloaded 85 times

Here is the workflow export:

Conditional.json

(9.18 KiB) Downloaded 91 times

And a zipped log folder:

sd-testFile_LogFolder.7z

(7.64 KiB) Downloaded 85 times

FFAStrans version: 1.3.0.2

Tell me if theres anymore information you need.

Thanks,
Lue

[emcodem]

Hey Lue,

very nice problem description, well done. Pretty sure you found a bug, what happens is that your jobs don't "finish" at all (because there is no full_log.json in the job log dir).
It occurs to me that the "reason" is that you make exhaustive use of a very little known and used feature, the "brown" connections. Not sure if you are aware what the "brown" connections are for but again, it's a little used feature and i'd advise you to only make use of it if you really need it.

I tested your wf and everything works without the brown connections, so the advise for workaround would be not to use brown connection type.

If you understand what the brown connection type is used for, you should also understand that these 2 workflows are doing literally the exact same thing, it is more or less just a different representation in the workflow editor. So it should not be a real problem for you to workaround the issue in production workflows.

broiwn.png (110.88 KiB) Viewed 1575 times

[lue3099]

Hi emcodem,

Thanks for the reply,
I do know what the brown connections are. But I still could be incorrect with how I interpret their use.
I've looked at the docs and seen the gif on how ffastrans orders the workflow limbs in regards to brown vs black lines.
I believe im using them right.

The first brown connection is not needed I guess as the text file doesn't change the source varible to the txt file... but the second I believe is. But again this is a recreation of a much larger workflow.
The delivery folder needs to be done after the hold. The hold doesn't actually exist. Its just representing the rest of the workflow that needs the original file before it gets "delivered" in there respective folders (thats why its after the conditional) or in the case of the larger workflow, archived.

Is there another way of getting one limb of the workflow done before/after another limb?
I imagine I would need to provide further context.

Regards,
Luke.

[emcodem]

OK perfect so you know exactly what you are doing, perfect!

Is there another way of getting one limb of the workflow done before/after another limb?

The answer is yes, by just using serial connections as usual. Also of course i could send you some example how to use the http+ plugin processor to execute and wait for a sub workflow. (as builtin sub-worklow does not wait for the sub to finish)

Basically the brown connection (let's say execute before" feature) does 2 things for you:
-) it saves you some workflow connections
-) s_source is preserved to the "current" value

One could say that it is a shortcut to make the workflow easier to build, but it does not deliver anything that you cannot do without brown connections.

This image shows how your workflow would look like without brown connections e.g. the hold (which represents a whole bunch of nodes) is exectuded before the delivery. At any point in the workflow, you can just store the current value of s_source and when you are done with the stuff you did under the brown connection, you can just restore s_source.

saverestore.png (115.82 KiB) Viewed 1556 times

Of course it is possible that there could be an easier workaround as soon as steinar investigated the issue but until then at least you got something to work with.

[lue3099]

Thanks emcodem for the work around. I'll see what I can do.

I will say though...
Would be nice to get those brown lines working correctly with conditionals. You said they are "very little known and used feature"
Having them makes alot of sense mentally when laying out a workflow...

Thanks,
Lue.

[emcodem]

I digged a little in the source code and tested, not yet 100% finished but so far it looks like it should work if you just avoid connecting "subhold" (the brown line) and error to the out pin of a single processor. E.g. insert a fake node to catch the error and connect your sub-stuff to this fake node.
So, only combine brown line with a success path after a processor, not with an error path.

Even if the problem might not be fixed in a way that you can combine error paths and subholds in future, it should at least give some error message to indicate whats wrong.

Btw, you will find (and can delete) lots of unprocessed tickets in C:\dev\FFAStrans\Processors\db\cache\tickets\temp - everytime a job was left behind unfinished by your found bug, it did write a ticket there, but the ticket should have been moved from temp to queue which just never happened.

[admin]

Hi lue3099,

Congrats, you found a logical flaw in how ffastrans evaluates these sub hold branches and thanks for reporting it!
We have found the cause and looking at solutions.

-steinar