2021.10.4

Release date: 7 April 2022

New(er) Mechanism for Launching Jobs Via Queue Triggers

After some recent back and forth in the area of queue triggers, we are readdressing the way queue triggers launch jobs with - what we hope to be the final and best - implementation of them all.

Problem statement: Whenever your queues contained fewer new items than items in progress, no jobs were launched despite robots being idle. This happened because the number of running jobs (actively processing queue items) would exceed the number of target jobs (jobs needed to process the new items).

Initial fix: Orchestrator accounted for both new and in-progress queue items when computing the number of target jobs, instead of only new items. Sounded good. Didn't work.

Brand new, shiny fix: Orchestrator accounts for new items when computing the number of target jobs, but looks at the number of pending jobs when deciding whether to launch a new job or not.

• Say you have 2 new items in a queue, and 2 pending jobs exist => then no new jobs are launched.
• Say you have 2 new items, and 1 pending job exists => then 1 new job is launched.

This ensures Orchestrator launches enough jobs to process all new items without going overboard.

Improvements

• We know your Ledger database tables can get quite crowded, thus requiring frequent cleanup. For this, we provide you a new cleanup script, allowing you to delete Ledger data every 7 days and to apply a batch size of 1,000 entries. Discover the new script in our documentation:

  • standalone Orchestrator installation
  • Automation Suite installation

Known Issues

• As a host, trying to end a maintenance window through Swagger UI may fail. This happens because Swagger UI uses cookies for authentication, which are lost when you close the browser.

  To end the maintenance mode via API, use one of the following workarounds:

  • Do not close the browser and make the POST request to /api/Maintenance/End from the Swagger UI.

  • Use an API testing application (for example, Postman) to:

    • retrieve an access token by exchanging your credentials to the /api.Account/Authenticate endpoint, and then
    • make a POST request to the /api/Maintenance/End endpoint using the Authorization: Bearer {access_token} header.

  • Run the following PowerShell script:

$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}

Bug Fixes

• An issue was fixed that would allow an attacker with privileged access to a robot to retrieve the LicenseKey (MachineKey) of other robots within the same tenant by brute forcing API calls to Orchestrator. This would theoretically allow the attacker to access resources restricted only to that robot.

  Read the security advisory for UiPath - Robot Account Takeover.

• Occasionally, job executions of long running workflows would get stuck in a Running state without being transitioned to a Suspended state. Upon killing those jobs, the jobs transitioned to and got stuck in a Terminating state. The underlying issue has been fixed and long running jobs are now transitioned to the different states as expected and are executed without issues.
• We made a typo on the Assign roles to a robot account window. Instead of Search for a robot account, the field said Seach for a robot account. The field name is now spelled correctly.
• The names of manually uploaded packages were not displayed in the audit details. This issue affected packages uploaded both individually and in bulk. Now, the names of all uploaded packages are successfully logged in the audit details.
• Users who did not have a Surname specified in Active Directory could not log in.