Workflow analyzer: rule for missing workflow xaml from invoke

Feedback Studio
, , ,
1

It appears that on 24.10.X the analyzer does not have a built-in rule for static-value invokes to workflows that don’t exist.

Repro:

  1. Create workflow1.
  2. Create workflow2, add an invoke to workflow1 in it
  3. Delete workflow1
  4. Run workflow analyzer/validate project/publish

Expected result:
At least a warning that a workflow invokes something that doesn’t exist (or can’t be validated to exist).
EDIT: potential regression
As noted by @J0ska in later post, this was an error on Invoke activity in earlier invoke versions, but no longer is the case.

Actual result:
No message.

While there are caveats to this, there is definite room for rules like:

  1. Invoke Workflow xaml file with relative path not found (default level: error, condition: const string as the xaml path (not a variable), path is relative).
    This one is a clear candidate for a new rule, as that’s just straight up a missing workflow.

  2. Invoke Workflow xaml file path passed as a variable (default level: warning, condition: variable used as the xaml path).
    This is IMHO a good candidate for a warning, as there are already similar rules that guide away from “you will most likely shoot yourself in the foot in the long term if you do this, but your call”.

  3. Invoke Workflow xaml file path should not be an absolute path (default level: ?, condition: const string as the xaml path (not a variable), path is absolute).
    This IMHO should also be at least a warning (preferably an error, or even critical by default), as it both can easily break and introduces an attack vector for the automation itself (quite literally a “go there and invoke whatever code you will find from an arbitrary path” - big no no).

Especially #1 and #3 are pretty clear cut cases, #2 is just a nice bonus (since all components for that rule would be needed for other ones already).

2 Likes
3

Hi @andrzej.kniola,

I was able to reproduce this behavior by following your steps.

But when I try to run that process, it throws me error:

The image shows a UiPath error message indicating that a specific workflow file, "Sequence.xaml," could not be found. (Captioned by AI)
The image shows a UiPath error message indicating that a specific workflow file, "Sequence.xaml," could not be found. (Captioned by AI)655×339 14.2 KB

So, you are basically publishing a project on orchestrator without actually running/testing it first which is not advisable as your project can still have errors.

Workflow analyzer is not a way to detect all kinds of errors in our project. It just an additional check that has to go hand-in-hand with debugging/testing the process to ensure a working process.

Its kind of like - some errors that are identified during run and some errors that are identified during analyzing project. Both have to be done in order to get a working project that also meets the high quality and reliability standards.

Even when you would see under governance policy, there multiple options to use workflow analyzer:

The image shows toggle settings for enforcing an analyzer at various stages, including Publish, Run, and Push/Check-In, with options for users to override them. (Captioned by AI)
The image shows toggle settings for enforcing an analyzer at various stages, including Publish, Run, and Push/Check-In, with options for users to override them. (Captioned by AI)429×473 17.6 KB

Regards
Sonali

4

Yes, I’ve run all 5 variations, actually:

Workflow analyzer - file
Workflow analyzer - project
Validate file
Validate Project
Publish (since it tries to actually package the whole thing, so it could theoretically find it as well)

None of the checks produced any entries (checked info level as well, just in case) on the invoke going to a missing file, or to an arbitrary absolute path, or to a variable passed path.

5

@andrzej.kniola

Please check my latest message.

6

I know it will fail on runtime, that’s my point - this is not a help/bug report after all, but feedback on workflow analyzer rules gap.
Just for context - this topic was sparked by a different topic in Help (link), where the user was switching from static invokes to dynamic dispatch based on variables (which will make the future maintainers suffer).

Static analysis should “protect” the developer from statically detectable defects in the produced code. The level of that defect can differ, and it can be argued what level should which issue be, but that’s a separate discussion.

Invoking a compile-time-evaluatable path that points to nowhere (case #1) falls straight into a “how did this pass the checks?” territory (it’s an equivalent of referencing a method/class that doesn’t exist, just with xaml’s). It’s as close to a compile-time error as you can get with xaml’s aside of straight up “does not parse” errors. There’s no edge cases, or nuance - this will fail at runtime, 100% of the time.

Invoking a workflow with the path passed as a variable (#2) is closest to a potential null dereference - it’s perfect for a warning. It’s not a per se error, but can easily lead to one in the future.

Invoking a workflow from an arbitrary absolute path (#3) is closest to loading assemblies from untrusted locations. There’s a reason why there’s layers on layers of security and checks in what can get loaded from where into the appdomain in traditional software. Performing a load like that with xaml’s (which are effectively just code) is an invitation for a code injection attack (and very brittle).

I do of course agree that static analysis is not end-all-be-all, and runtime tests are needed, that’s not even a question. But, at the same time, if something can be a compile-time error because it’s 100% guaranteed to fail when run (case #1), it should not be a runtime error. The other ones are just good warnings to have.
And I’m not even advocating for the #1 case to be a compile-time error (although IMHO it could be), just an analyzer error.

Let’s put it in perspective:
The analyzer gives warnings for things like 2 activities having the same name (because it could potentially make debugging more difficult) even if those activities physically cannot fail (static value log messages, for example).
It gives an error if a workflow has too many arguments. There’s nothing inherently unsafe about it, it’s just not really too good maintenance.

The examples could be numerous - a lot of what the analyzer does falls under design style, security and maintainability (the other ones being enforcing organizational rules). Proposed rules, in my opinion, fit well into that style.

(although the more I think about it, that #1 case should be a compile-time error, because it will never ever work)

7

Actually the same behavior in Studio 23.10.9

In case of earlied System.Activities it at least indicated the XAML file not exists

image
image372×144 5.74 KB

In later version it doesn’t

image
image368×183 3.71 KB

Cheers

2 Likes
8

Thank you!
I was really getting a “am I tripping or did that check exist before?” moment. Looks like it was omitted (by accident or maybe on purpose, for some reason) when the invoke got redesigned.
Adding a bug tag here just in case, as it might be an unwanted regression.

9

Also apparently this was suggested 4 years ago as well:

1 Like
10

@andrzej.kniola

Thanks for sharing in detail, makes sense.

As it was an inbuilt feature before as shared by @J0ska , it would make more sense to have that back itself.

Regards
Sonali

11

Hi @andrzej.kniola !

Could you maybe create 2 minimal example projects and put these up as a repo on e.g. GitHub?

Because beyond the bug you seem to describe a requirement where you want to detect if InvokeWorkflow is supplied a “non literal” argument for WorkflowFileName – which is worth following up.
But even after reading the linked Help thread I am only 90% sure that I got all nuances.

Your input will be well received, see my LinkedIn post #procrastinating #uipath | Christian Prior-Mamulyan? how I am currently pushing the Workflow Analyzer topic.