I thought I’d raise awareness about an issue that just recently began happening.
I frequently use Check App State to determine if a screen element appears and take different actions. I’ve used it because it’s a best practice rather than trying to click one thing and using a try/catch to handle it if it didn’t appear.
I just noticed this week after starting a new project with fully updated libraries that when the Check App State goes down the “Target does not appear” branch, it results in an error log which is somewhat confusing:
message:
‘Check App State ‘F9=Display password rul…’’ activity recovery failed. No available license / Agentic units to perform healing analysis and recovery.
The target appearing or not appearing is not an error that needs healing analysis and recovery, either is an expected outcome with different paths. That IS the intended use of Check App State, is it not?
This is happening in all cases where I am using Check App State and the “Target does not appear” branch is used.
UiPath have added support for Healing Agent on Check App, but only for “wait to appear” configuration.
By default, the Healing Agent is disabled for Check App, and the user must explicitly enable it in activity settings. The error message saying there are no Agentic units should not appear and will be fixed in a future update. It can be ignored for now.
Hi @marian.platonov. I was looking for a thread on this issue (or more of an annoyance, I’d say).
We’re having a few processes that are heavy on the UI navigation side, so there are quite a few components meant to scan for various pop-ups and act accordingly based on few scenarios possible.
The problem is that since the healing agent upgrade, which is completely disabled on our end for all UI activities, we get spammed with these logs. On our use-cases, many UI elements are meant to not be there all the time, so we don’t need to see any log, instead, we’ve got 77 pages (50 lines/page) with healing agent spam logs, out of a total of 180 log pages, for a process that ran about 12 hrs. This makes it impossible to actually make any use of error filtering in Orchestrator. We have to export the logs and clean it first.
It’s this something that can be fixed rather soon? If healing agent is disabled then there should be no log. It makes no sense to get a log like “-check app state activity display name- activity recovery failed. No available license / Agentic units to perform healing analysis and recovery.” in this context.
I haven’t seen any option to turn this logging off as it is the case with audit logs, and I’m particularly stressing over, because we’ve had the same spam with audit logs, especially on the Excel package for over a year. I think that was finally fixed now in 3.1.1.
This behavior was fixed in UiPath.UiAutomation.Activities.25.10.8 patch. The error message can be ignored, there are no side effects on the UiPath side.
Downgrade/upgrade and use UiPath.UiAutomation.Activities.24.10.14 patch in your project, as this version doesn’t require Healing Agent add-on.
Try to add "DisableActivityRecovery": true under the project.json file under runtimeOptions section.
Disable the Orchestrator notification subscription for Detected Job Issues via Healing Agent under https://cloud.uipath.com/YOUR_ORG_NAME/portal_/profile/notification-settings
Under the Orchestrator Job, disable the Enable Healing Agent
