Aria Automation Custom Forms Stuck Buffering and Failing to Populate

Products

VCF Automation

Issue/Introduction

Users may experience an issue where the custom form fields fail to load properly. When accessing a custom form, the fields may appear stuck in a buffering loop, unable to fetch data, and may throw the error below:

Some data cannot be retrieved. If the problem persists, contact your system administrator. Failed request:
com.vmware.vro.actions.provisioning.presentation/getStorageTag.; Some data cannot be retrieved. If the problem persists, contact your system administrator. Failed request:
com.vmware.vro.actions.provisioning.presentation/getClusterTag.; Some data cannot be retrieved. If the problem persists, contact your system administrator. Failed request:
com.vmware.vro.actions.provisioning.presentation/getLocationIdForCustomHostname.; Some data cannot be retrieved. If the problem persists, contact your system administrator. Failed request:
com.vmware..vro.actions.provisioning.presentation/getEnvironments.; [13][storage.value][com.vmware.vro.actions.provisioning.presentation/getStorageTag] The request did not return a response.; [14][cluster.value][com.vmware.vro.actions.provisioning.presentation/getClusterTag] The request did not return a response.; [15][locationId.value][com.vmware.vro.actions.provisioning.presentation/getLocationIdForCustomHostname] The request did not return a response.; [16][subApplicationName.value][com.vmware.vro.actions.provisioning.presentation/fetchSubAppName] The request did not return a respo... (less)

Additionally, we may also encounter deadlocks in the workflows due to the use of the LockingSystem. When workflows become unresponsive or appear to hang, it is recommended to check for active locks in the system. These locks can be identified using the out-of-the-box (OOB) LockingSystem workflows. If such locks are present, removing or clearing them can help unblock and resume the affected workflow executions.

2026-04-09T09:09:19.453Z INFO vco [host='vco-app-cxxxxxxx-xxxxxx' thread='WorkflowExecutorPool-Thread-267' user='REDDIRA4' org='exxxxxx-xxxx-xxxx-xxxx-dxxxxxxxx' trace='-'] {|__SYSTEM|REDDIRA4:Initialize Server Decommission:6xxxxxx-2xxxx-4xxxx-9xxxx-4xxxxxxxx:token=e94xxxxx-2xxxx-4xxx-axxxx-fxxxxxxxx} ch.dunes.scripting.server.script.MainScriptingObject - executeScript //Obtain lock using workflow.name so that only 1 instance of this workflow may run concurrently LockingSystem.lockAndWait(workflow.name, workflow.id); Workflow:Initialize Server Decommission / Obtain Lock (item2)

You can verify if your environment is experiencing this specific issue by cross-referencing the Form Service and vRO Server logs for matching timestamps.

1. Form Service Log (form-service-app.log) You will see WARN messages indicating that the requested actions were forcibly canceled due to the execution delay:
WARN form-service [...] c.v.f.s.s.impl.ExternalValueServiceImpl - Request to execute actions has been cancelled! Cancelled actions: [#13:.../getStorageTag, #14:.../getClusterTag, #15:.../getLocationIdForCustomHostname, #16:.../fetchSubAppName, #17:.../getProjectName...]

2. vRO Server Log (vco-server-app.log) At the exact same time the actions are attempting to execute, you will see DEBUG messages indicating a database locking conflict for the vRA authenticator:
DEBUG vco [...] ch.dunes.scripting.server.locking.LockingSystem - Object 'com.vmware.library.ts.vra.authentication' already locked, owner 'vRAAuthenticator' is waiting...
DEBUG vco [...] ch.dunes.scripting.server.locking.JdbcLocking - Unable to insert row

Environment

Aria Automation 8.18.x

Cause

The continuous buffering issue is caused by a temporary resource lock in Aria Automation Orchestrator (vRO) that occurs when the custom form attempts to execute external actions to fetch data.

This behavior is not caused by a product defect in the Aria Automation Form Service, Gateway, or vRO. Instead, it is a script execution issue stemming from the locking logic written into the custom vRO action.

Resolution

The continuous buffering occurs because the custom action script does not handle locks efficiently, which can cause the form request to time out. To permanently resolve this issue, the custom action script should be refactored to implement proper lock management and ensure that locks are acquired and released efficiently during execution.

Workaround

As a temporary workaround, you can perform the following steps to identify and manage locks associated with the problematic action:

Manually execute the problematic action directly from the vRO client.
While the action is running, quickly navigate to the Locks tab on the vRO Dashboard to observe whether any locks are created during execution.
In the vRO client, open the API Explorer from the left-hand panel.
Search for locking to locate the LockingSystem object.
Use the available methods within LockingSystem to review, lock, or unlock objects within vRO scripts as needed.

This approach can help identify lock-related issues and temporarily mitigate the buffering behavior until the script is updated to properly manage locking.

Additional Information

If you need to investigate this behavior further or prepare data for a Support ticket, you can use the following steps to gather more information within Aria Automation Orchestrator (vRO).

1. Enable Debug Logging To capture the underlying transient lock events, you will need to enable debug logs in vRO and then reproduce the continuous buffering issue.

Navigate to System Settings.
Select Log Configuration.
Change the log level to Debug. (Note: Be sure to reproduce the form buffering issue immediately after enabling this so the events are captured in the logs.)

2. Verify Active Locks Although the locks causing this specific issue are usually temporary and release on their own, it is good practice to confirm there are no persistent locked actions stuck in the system.

Navigate to the vRO Dashboard.
Locate the Requiring Attention table.
Click on the Locks column to review any currently locked objects.