@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-troubleshoot/references/activity-packages/ui-automation/summary.md

@@ -26,6 +26,6 @@
 | Activity Configuration Error — Invalid Property Value | High | An activity faulted on its own property validation: Mouse Scroll `Movement units` < 1 or missing searched element, Keyboard Shortcuts empty/invalid sequence, Take Screenshot missing `File name` / `Saved image` | [activity-configuration-error.md](./playbooks/activity-configuration-error.md) |
 | Element Found But Not Actionable | Medium | Element located but stale (`InvalidNodeException` / `UiNodeUninitializedElementException`), not visible (no screen rectangle / `TargetFoundButNotVisibleException`), or blocked by a browser dialog (`TargetNotFoundBrowserBlockedException`) | [element-found-not-actionable.md](./playbooks/element-found-not-actionable.md) |
 | Select Item — Container Has No Items | Medium | `UiNodeHasNoItemsException` ("The target container does not have any items.") — Select Item's dropdown/list was empty at action time | [select-item-no-items.md](./playbooks/select-item-no-items.md) |
-| Click Silent No-Op — Reported Success But Did Nothing | Medium | **No signature** (no exception, job `Successful`, zero Error logs). An input activity (`NClick`, `NTypeInto`, `NSetText`, `NCheck`, `NSelectItem`, `NHover`, `NKeyboardShortcuts`) posted its event and reported success, but the effect never landed. Causes: input method unsupported by the target tech (`Simulate`/`SendWindowMessages` on Java/SAP/legacy Win32), covering overlay, wrong/duplicate element, lost focus, DOM race — undetected because Verify Execution is absent or inert. Counterpart to verify-execution-failure.md (which fires when Verify WAS set and threw). Route here via the no-signature table. | [click-silent-no-op.md](./playbooks/click-silent-no-op.md) |
+| Click Silent No-Op — Reported Success But Did Nothing | Medium | **No signature** (no exception, job `Successful`, zero Error logs). An input activity (`NClick`, `NTypeInto`, `NSetText`, `NCheck`, `NSelectItem`, `NHover`, `NKeyboardShortcuts`) posted its event and reported success, but the effect never landed. Causes: control did not act on the API-level event under `Simulate`/`SendWindowMessages` (per-element, NOT a Java/SAP technology rule - Simulate is supported and recommended there), covering overlay, wrong/duplicate element, lost focus, DOM race — undetected because Verify Execution is absent or inert. Counterpart to verify-execution-failure.md (which fires when Verify WAS set and threw). Route here via the no-signature table. | [click-silent-no-op.md](./playbooks/click-silent-no-op.md) |
 | Type Into (NTypeInto) — Text Corrupted / Not Typed / Method-Not-Found | Medium | Entry point for "Type Into isn't working." OWNS two modes: (1) **text integrity** — value typed is present but wrong (missing/scrambled/duplicated/out-of-order chars, or nothing typed) usually on a `Successful` job; caused by `HardwareEvents` typing faster than the target accepts (`DelayBetweenKeys` too low), lost focus, unsupported input method for Java/SAP, or field not cleared (`EmptyField`); fix = raise `DelayBetweenKeys` / switch input method / `EmptyField=True` / last-resort `Set Text`. (2) **`Method not found: 'Void UiPath.UIAutomationNext.Activities...'`** — `UiPath.UIAutomation.Activities` package version skew between build and run environments; fix = align the package version everywhere. ROUTES selector/timeout/ambiguous/disabled/off-screen/pure-no-op/verify-throw cases to their playbooks. | [type-into-input-failed.md](./playbooks/type-into-input-failed.md) |
 | Dependency / Version Conflict — UIAutomationNext Assembly Fails to Bind | Medium | Activity fails **before** any selector is evaluated because the `UiPath.UIAutomationNext.Activities` assembly can't load/bind. `MissingMethodException` "Method not found: 'Void UiPath.UIAutomationNext.Activities…'" (version mismatch inside `project.json`'s dependency set → align in Manage Packages) vs `FileNotFoundException`/`FileLoadException` "Could not load file or assembly" (works in Studio, fails in Assistant/robot → clean `%userprofile%\.nuget\packages`, verify feed, republish Lowest Applicable/Strict). Distinct from selector/targeting failures. | [dependency-version-conflict.md](./playbooks/dependency-version-conflict.md) |

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/overview.md

@@ -30,6 +30,10 @@ Unlike connection-based packages (O365's `Office365Exception`, Integration Servi
 - **Malformed payload** — `DeserializeJson` / `DeserializeJsonArray` throw `JsonReaderException`, `DeserializeXml` throws `XmlException`, when the input string is not valid JSON/XML. Frequently a **symptom of an upstream HTTP activity** that returned an HTML error page, an empty body, or a non-JSON error envelope.
 - **Type mismatch** — `DeserializeJson` throws `JsonSerializationException` when well-formed JSON does not match the target type `T`.
 - **Null/empty payload** — `DeserializeJson` throws `ArgumentNullException` (param `JSON string`); `DeserializeJsonArray` throws `NullReferenceException` for the same null input.
+- **Payload rejected (400/415)** — a `POST`/`PUT` body or attachment is refused on media type: `Content-Type` vs body mismatch (`BodyFormat` defaults to `application/xml`) or a file sent with the wrong shape (`multipart/form-data` vs JSON). Reached the server; not auth/path/transport.
+- **Proxy-blocked egress** — `StatusCode 0` / `NULL` / `(407)` / timeout, robot-only, when the environment's corporate proxy is not in the request path (the activities expose no proxy property).
+- **Design-time package/Studio mismatch** — `MissingMethodException` "Method not found: 'Void UiPath.Web.Activities...'" on open/validate/wizard when `UiPath.WebAPI.Activities` is incompatible with the installed Studio or skewed against `UiPath.System.Activities`. Not a runtime fault.
+- **Design-time ST-SEC-009** — Workflow Analyzer flags a `SecureString`→`String` conversion into an HTTP header (or over-wide `SecureString` scope). A secure-coding lint, not an activity fault.
 
 ## Package
 

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/playbooks/http-request-auth-401-403.md

@@ -0,0 +1,44 @@
+---
+confidence: medium
+---
+
+# HTTP Request — 401 Unauthorized / 403 Forbidden (auth)
+
+## Context
+
+What this looks like:
+- An `HttpClient` / `NetHttpRequest` call is answered by the server with **`(401) Unauthorized`** or **`(403) Forbidden`**.
+- Legacy `HttpClient` surfaces it as `System.Net.WebException: The remote server returned an error: (401) Unauthorized.` (a faulted job). `NetHttpRequest` (default `ContinueOnError = True`) returns it as a **response** with `StatusCode 401`/`403` — read the response, not a fault.
+- The request **reached the server and was authenticated-checked** — this is a credential/authorization problem, NOT transport (DNS/connection/TLS), NOT a payload/media-type problem (`400/415`), NOT a proxy `407`.
+
+What causes it (branch on the code):
+- **`401` Unauthorized — the caller was not authenticated.** Common causes:
+  - **Missing / malformed `Authorization` header** — the classic one is sending the **bare token** instead of the scheme-prefixed value: the header must be `"Bearer " + tokenVariable`, not just `tokenVariable`. A missing `Bearer ` prefix (or wrong scheme, e.g. `Basic` vs `Bearer`) → `401`.
+  - **Expired / revoked token**, or a token minted for a different environment/audience.
+  - **Token in the wrong place** — query string vs header, or a custom header name (`X-API-Key`) the API doesn't read.
+- **`403` Forbidden — authenticated but not permitted.** The token is valid but the identity lacks the scope/role/permission for that resource, or the API key is out of quota / IP-restricted.
+
+What to look for:
+- **The exact status in the message/response** — `401` (authN) vs `403` (authZ) selects the branch.
+- **The `Headers` in the workflow source** — is there an `Authorization` header, and is its value `"Bearer " + token` (scheme prefix present) or a bare token? Is the token literal, a variable, or an unset value?
+- **Token source & freshness** — Get Credential / Orchestrator asset vs hard-coded; whether it is refreshed per run or reused past expiry.
+- **What a known-good client sends** — the same request in Postman / curl that succeeds. Header/scheme parity with the working client is the fastest confirmation.
+
+## Investigation
+
+1. **Confirm the status is `401` or `403`** (not `400/415`, `407`, or a transport `WebException`). `uip or jobs get <job-key> --output json` / `uip or jobs logs <job-key> --level Error --output json` (legacy fault) or the activity's response output (`NetHttpRequest`).
+2. **Read the auth configuration from source** — the `Authorization` header value expression, `AuthenticationType`/auth properties, and where the token comes from. Note whether the scheme prefix (`Bearer `) is present.
+3. **Branch:**
+   - `401` → authentication: check the header format/scheme prefix, token presence, and token freshness/audience.
+   - `403` → authorization: the token is accepted but lacks scope/role/permission (or key quota / IP restriction).
+4. **Compare to a known-good request** (Postman/curl) — replicate its headers exactly; a difference in the `Authorization` value or a missing header is the cause.
+
+## Resolution
+
+- **401 — fix the credential presentation:**
+  - Format the header with its scheme: `Authorization = "Bearer " + tokenVariable` (do not send the bare token; match the scheme the API documents).
+  - Supply a **fresh, valid** token (refresh per run; retrieve via Get Credential / an Orchestrator credential asset rather than a stale literal), minted for the **correct environment/audience**.
+  - Put the credential where the API expects it (header vs query; correct header name).
+- **403 — fix authorization:** grant the identity the required scope/role/permission on the target API, or use a principal/key that has it; check API-key quota and any IP allowlist.
+- **Confirm against a known-good client** — mirror the exact headers of a succeeding Postman/curl call, then re-run and confirm a `2xx`.
+- Do not treat `401/403` as a transport, proxy, or endpoint-path problem — the server answered; correcting DNS/proxy/URL will not change an auth rejection. For the raw-transport / DNS / TLS branch see [http-request-connection-failure.md](./http-request-connection-failure.md); for secure handling of the token itself (Workflow Analyzer ST-SEC-009) see [securestring-misuse-analyzer.md](./securestring-misuse-analyzer.md).

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/playbooks/http-request-connection-failure.md

@@ -42,7 +42,8 @@ What to look for:
 
 ## Resolution
 
-- **Non-success status:** fix per code — supply/refresh credentials or scope (`401/403`); correct the `EndPoint` path or resource id (`404`); add backoff / reduce call rate (`429`); for `5xx`, treat as a target-service fault — retry, or escalate to the API owner if persistent.
+- **Non-success status:** fix per code — supply/refresh credentials or scope (`401/403` — for the header-format / `Bearer`-prefix / scope specifics see [http-request-auth-401-403.md](./http-request-auth-401-403.md)); correct the `EndPoint` path or resource id (`404`); add backoff / reduce call rate (`429`); for `5xx`, treat as a target-service fault — retry, or escalate to the API owner if persistent. A `400/415` on a POST/PUT body is a payload/`Content-Type` problem — see [http-request-content-type-rejected.md](./http-request-content-type-rejected.md).
 - **DNS failure:** correct the host in `EndPoint`; ensure the robot machine can resolve it (DNS server / hosts entry / VPN).
 - **Connection refused / unreachable:** confirm the service is listening on the expected port and that the robot's network/proxy/firewall allows egress to it.
 - **SSL/TLS failure:** install/trust a valid server certificate (or fix the expired one); align the TLS version; trust the intercepting proxy's CA on the robot machine. Disabling `EnableSSLVerification` masks the problem and is not a fix for production endpoints.
+  - **Do NOT recommend the `ServicePointManager.SecurityProtocol = Tls12` Invoke Code fix.** It circulates widely on forums but is obsolete and **has no effect on the modern UiPath runtime** (`targetFramework: Windows`, .NET 6+): `ServicePointManager` does not configure `SocketsHttpHandler`, which backs both `NetHttpRequest`'s `System.Net.Http.HttpClient` and the legacy `HttpClient` transport on .NET 6+. It is a global, per-AppDomain hack from the .NET Framework era. TLS 1.2/1.3 is already the default on the supported runtime — a "secure channel" failure is a **certificate-trust, TLS-version-floor, or proxy-interception** problem at the endpoint, not a client protocol default to flip. Fix the trust/version/proxy issue above instead.

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/playbooks/http-request-content-type-rejected.md

@@ -0,0 +1,37 @@
+---
+confidence: medium
+---
+
+# HTTP Request — Payload Rejected (400 Bad Request / 415 Unsupported Media Type)
+
+## Context
+
+What this looks like:
+- A **`POST` / `PUT`** HTTP request that sends a body or a file is answered by the server with **`(400) Bad Request`** or **`(415) Unsupported Media Type`**.
+- On the legacy `HttpClient` this surfaces as `System.Net.WebException: The remote server returned an error: (415) Unsupported Media Type.` (a faulted job); on `NetHttpRequest` (default `ContinueOnError = True`) it is returned as a **response** with `StatusCode 415`/`400` (no fault) — read the response, not a fault.
+- The request reached the server and was **understood enough to be rejected** — this is a payload/formatting problem, NOT auth (`401/403`), NOT a wrong path (`404`), NOT transport.
+
+What causes it:
+- **`Content-Type` does not match the body.** `HttpClient`'s `BodyFormat` defaults to **`application/xml`**; sending a JSON body without setting `BodyFormat`/the `Content-Type` header to `application/json` → the server rejects the media type (`415`) or fails to parse (`400`).
+- **Attachments sent with the wrong shape.** The **Add Attachment** option is enabled **only when the Method is `POST` or `PUT`**. Posting a file the API expects as **`multipart/form-data`** while the request advertises `application/json` (or vice versa) → `415`/`400`. Mixing an explicit body with attachments can also produce a malformed request.
+- **Header vs body mismatch** — a hand-set `Content-Type` header that contradicts the actual body encoding.
+
+What to look for:
+- **The status code in the message/response** — `415` = server refused the media type; `400` = server could not parse/validate the payload as sent.
+- **`Method`** — `400/415` on a body/file almost always accompanies `POST`/`PUT`.
+- **`BodyFormat` and the `Headers`** in the workflow source — is `Content-Type` set, and does it match the actual `Body`?
+- **Attachments** — is a file attached, and does the API expect `multipart/form-data`?
+- **The API's documented `Content-Type` requirement** for this endpoint.
+
+## Investigation
+
+1. **Confirm the status is `400` or `415`** (not `401/403/404`). `uip or jobs get <job-key> --output json` / `uip or jobs logs <job-key> --level Error --output json` (legacy fault) or the activity's response output (`NetHttpRequest`).
+2. **Read the request configuration from source** — `Method`, `BodyFormat`, the `Content-Type` header, the `Body` value, and whether Add Attachment is used.
+3. **Compare the advertised `Content-Type` to the actual body / attachment shape** and to what the API documents it accepts. The mismatch is the root cause.
+
+## Resolution
+
+- **Set the `Content-Type` to match the body.** For a JSON body, set `BodyFormat` / the `Content-Type` header to `application/json` (do not rely on the `application/xml` default). Align header and body encoding.
+- **Use the media type the API expects for files.** For a file upload the API wants as `multipart/form-data`, send it via the attachment mechanism with `multipart/form-data` — do not stuff the file into a JSON body; conversely do not attach a file when the API expects a raw JSON/binary body.
+- **Keep attachments on `POST`/`PUT`** (the only methods that allow them) and avoid combining a conflicting explicit `Body` with attachments.
+- Re-run and confirm a `2xx`. Do not treat `400/415` as an auth or endpoint-path problem — supplying credentials or changing the URL will not fix a media-type mismatch.

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/playbooks/http-request-proxy-blocked.md

@@ -0,0 +1,39 @@
+---
+confidence: medium
+---
+
+# HTTP Request — Blocked by Corporate Proxy (StatusCode 0 / 407)
+
+## Context
+
+What this looks like:
+- An `HttpClient` / `NetHttpRequest` call to an **external/public** endpoint returns a **`StatusCode` of `0`** (or `NULL`/empty response), or fails with **`(407) Proxy Authentication Required`**, or a connection timeout/abort — **only from the robot machine / a virtual or server environment**, while the same call works from a developer laptop.
+- StatusCode `0` means **no HTTP response reached the activity** — the request never made it to the server. It is a transport/connectivity signal, not a server answer.
+- Internal/intranet endpoints succeed; only egress to the internet fails. The differentiator is the **network path**, not the request itself.
+
+What causes it:
+- The environment sits behind a **corporate proxy** required for outbound internet, and the request is not traversing it. The Web activities do **not** expose a built-in proxy configuration, and do not reliably pick up the interactive user's system proxy when running under a **service/unattended** account (Session 0) — so egress is dropped by the firewall/proxy.
+- **`407`** specifically = the proxy is in the path but the request carries **no proxy credentials**.
+
+What to look for:
+- **`StatusCode == 0`, `407`, or a timeout/abort with no HTTP status** — the transport signal.
+- **Endpoint is external** (public internet) vs internal — external-only failure points at egress/proxy.
+- **Run context** — unattended/service account vs interactive; failure on a server/VM but not the author's machine.
+- **Whether a proxy is required for internet egress** in this environment (ask / check environment policy).
+- This is distinct from a **DNS / connection-refused / TLS `WebException`** (host resolves but call fails for a server/cert reason) — for those see [http-request-connection-failure.md](./http-request-connection-failure.md). Here the host is reachable *in principle* but the proxy hop is missing.
+
+## Investigation
+
+1. **Capture the symptom.** From logs/traces or the workflow output: is it `StatusCode 0`, `407`, or a timeout with no status? `uip or jobs logs <job-key> --level Error --output json` / `uip or jobs traces <job-key> --output json`.
+2. **Confirm the endpoint is external** and that the failure is environment-specific (robot/server, not the developer machine).
+3. **Establish whether a proxy governs internet egress** in that environment and whether the robot's run account routes through it.
+4. **Rule out a plain transport failure** — if the message is a `WebException` naming DNS / "Unable to connect" / SSL, that is [http-request-connection-failure.md](./http-request-connection-failure.md), not a proxy gap.
+
+## Resolution
+
+- **Route the request through the proxy.** Because the activity has no proxy property, either:
+  - Configure the **robot's run account / machine** to use the corporate proxy for outbound HTTP (system proxy for the service account, or `HTTP_PROXY`/`HTTPS_PROXY` where honored), OR
+  - Set the proxy **programmatically** before the call — build `New System.Net.WebProxy(proxyAddress)`, set `NetworkCredential` for the `407` case, then `System.Net.WebRequest.DefaultWebProxy = proxy` (Assign activities, ahead of the HTTP request).
+- **Supply proxy credentials** when the symptom is `407`.
+- **Whitelist the target host** for egress on the corporate proxy/firewall, or add it to the proxy **bypass list** (`proxy.BypassProxyOnLocal`, `proxy.BypassList`) when it should skip the proxy.
+- Verify from the **robot machine under the run account** (not the author's machine) that egress to the endpoint now returns a real status code.

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/playbooks/package-version-mismatch.md

@@ -0,0 +1,42 @@
+---
+confidence: medium
+---
+
+# Web Activities — Package / Studio Version Mismatch (design-time)
+
+## Context
+
+What this looks like:
+- A **design-time** failure in Studio — the project fails to open, validate, or the **HTTP Request wizard** ("Configure" on the activity) throws — with one of:
+  - `System.MissingMethodException: Method not found: 'Void UiPath.Web.Activities...'` (or a similar `Method not found` on a `UiPath.Web.Activities` / `UiPath.WebAPI.Activities` type)
+  - `HTTP Request` / `HTTP Client` shows as a **missing/unknown activity** ("Activity could not be loaded"), or the package fails to restore
+  - The wizard opens then errors on **Configure**, while the same call runs fine at execution time on another machine
+- The process **has not necessarily run** — this reproduces when opening / validating / configuring in Studio, not as an Orchestrator job fault.
+
+What causes it:
+- **`UiPath.WebAPI.Activities` version incompatible with the installed Studio.** A package built for a newer Studio (e.g. `1.11.1` requires Studio `22.4+`) loaded on an older Studio (e.g. `21.10`) → the wizard/activity calls a member the older Studio assemblies do not expose → `Method not found`. Documented UiPath KB.
+- **Version skew across the project's own dependency set** — `UiPath.WebAPI.Activities` bumped in isolation while `UiPath.System.Activities` stays on an older line, so the resolved Web assembly binds against an older System runtime. (Same class as the UI Automation `dependency-version-conflict`, Signature A — for that package see `../../ui-automation/playbooks/dependency-version-conflict.md`.)
+- **Legacy vs modern HTTP Request confusion.** The activity was renamed/reworked across the package line: the **legacy** HTTP Request ships in `UiPath.WebAPI.Activities` **earlier than `2.0.0-preview`**; the **modern** HTTP Request ships in `2.0.0-preview`+, and the **current** HTTP Request in **`2.3.0`+**. A workflow authored against one line, opened with the other package installed, can show missing-member / missing-activity errors.
+
+What to look for:
+- **`project.json` `dependencies`** — the pinned `UiPath.WebAPI.Activities` version AND `UiPath.System.Activities` version.
+- **`project.json` `studioVersion`** (and the Studio version in the user's report) — the package's minimum-Studio requirement vs the installed Studio.
+- **Whether the exception is `MissingMethodException` / `Method not found`** — this means the assembly **loaded** but a member is **absent** (a version-mismatch hallmark), NOT that a file is missing.
+
+## Distinguish from the runtime assembly-load failure
+
+`MissingMethodException` / `Method not found` at **design time** is NOT the runtime `System.IO.FileNotFoundException` / `FileLoadException` "**Could not load file or assembly 'UiPath.WebAPI.Activities'**" fault (works in Studio, fails on the robot because the robot's NuGet cache / Orchestrator feed cannot supply the pinned version). If the symptom is the runtime assembly-load fault, the fix is clearing the robot NuGet cache / republishing against a resolvable feed — do NOT apply the version-alignment fix below.
+
+## Investigation
+
+1. **Confirm it is design-time.** No faulted Orchestrator job; the error appears on open / validate / wizard-Configure. `uip or jobs list ... --state Faulted --output json` returns empty for this process.
+2. **Read the dependency set from source.** Open `project.json`: capture `UiPath.WebAPI.Activities`, `UiPath.System.Activities`, and `studioVersion`.
+3. **Compare against the installed Studio.** Determine the package's minimum Studio requirement (Manage Packages shows it) and whether the installed Studio meets it. A package ahead of the Studio line is the primary suspect.
+4. **Confirm the exception class.** `MissingMethodException` / `Method not found` → member absent → version mismatch (this playbook). "Could not load file or assembly" → missing assembly → see the runtime distinction above.
+
+## Resolution
+
+- **Align the package to the installed Studio.** In **Manage Packages**, set `UiPath.WebAPI.Activities` to a version whose minimum-Studio requirement the installed Studio satisfies (upgrade the package, or upgrade Studio to the line the package needs).
+- **Update foundational packages together.** Move `UiPath.WebAPI.Activities` and `UiPath.System.Activities` to the same mutually compatible, latest-stable line — do not bump one in isolation. Reopen / revalidate the workflow.
+- **Match the HTTP Request line to the workflow.** If the workflow was authored against the current HTTP Request, ensure `UiPath.WebAPI.Activities >= 2.3.0`; if it must stay on the legacy activity, keep the package below `2.0.0-preview`.
+- Do NOT clean the NuGet cache / republish for a design-time `Method not found` — the assembly loads; a member is missing. Cache cleaning is the fix for the runtime assembly-load fault only.

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/playbooks/securestring-misuse-analyzer.md

@@ -0,0 +1,41 @@
+---
+confidence: medium
+---
+
+# HTTP Activity — Workflow Analyzer ST-SEC-009 (SecureString Misusage, design-time)
+
+## Context
+
+What this looks like:
+- A **design-time** Workflow Analyzer finding — **`ST-SEC-009` SecureString Misusage** — raised against an `HttpClient` / `NetHttpRequest` (or its surrounding Assign). At **Error** severity it blocks validate/publish; at Warning it flags the file. No runtime job is involved.
+- Typical trigger: a credential/API token held as a **`SecureString`** (e.g. from **Get Credential** / an Orchestrator credential asset) is **converted to a plain `String`** to build an `Authorization` / API-key **header** — e.g. `new System.Net.NetworkCredential(String.Empty, secureToken).Password`, `.ToString()`, or `Marshal.PtrToStringBSTR(...)` — and/or the `SecureString` variable is **scoped wider** than the activity that needs it.
+
+What causes it (per the rule):
+- **ST-SEC-009 flags casting `SecureString` to `String`** and `SecureString` variables whose scope extends beyond where they are created. The Web activities' `Headers` dictionary takes plain strings, so putting a secret in a header requires a `SecureString→String` conversion — which is exactly what the rule catches. This is a **secure-coding lint, not an activity bug**.
+
+What to look for:
+- The **conversion expression** feeding the header (`NetworkCredential(...).Password`, `.ToString()`, `Marshal.*`).
+- The **scope** of the `SecureString` variable — is it declared at the whole workflow/`Sequence` level rather than the minimal container?
+- The **rule severity** in Project Settings → Workflow Analyzer (Error blocks build; Warning does not).
+
+## Do NOT recommend a package upgrade as the fix
+
+Upgrading `UiPath.WebAPI.Activities` (e.g. to `2.3.0+`) does **NOT** resolve ST-SEC-009 and does **not** add "native SecureString-in-headers" handling — the header dictionary is still plain-string, so the conversion (and the finding) remain. This is a common but **false** fix. The finding is about how the secret is handled in the workflow, addressed by scoping + secure storage + (optionally) excluding the activity from the rule — see below.
+
+## Do NOT invent a SecureString header property
+
+`HttpClient` has **no** `AuthenticationType` property and its `OAuth2Token` is a **plain `String`**, not a `SecureString` — routing a bearer token through `OAuth2Token` still requires a `SecureString`→`String` conversion and does not clear ST-SEC-009. The only SecureString-typed auth input is **`SecurePassword`**, and it applies to **Basic (Username/Password) authentication only** — not to a bearer/API-key header. For a header-borne token there is no SecureString escape hatch on the activity; the fix is scoping + secure storage + point-of-use conversion + (optionally) rule exclusion, below.
+
+## Investigation
+
+1. **Confirm it is design-time** (Workflow Analyzer, not a job fault) and read the exact rule id/severity.
+2. **Find the SecureString→String conversion** in the workflow source that feeds the HTTP header, and note the `SecureString` variable's scope.
+3. **Confirm the secret's source** — Get Credential / Orchestrator asset (good) vs a hard-coded or broadly-scoped value (worse).
+
+## Resolution
+
+- **Minimise scope.** Retrieve the secret with **Get Credential** and keep the `SecureString` variable scoped to the smallest container (the `Sequence` that builds and sends the request), so it is disposed as soon as that scope completes.
+- **Store the secret securely.** Use an **Orchestrator Credential asset / credential store** — never a hard-coded key or a plain-`String` variable that lingers.
+- **Convert at the point of use only**, inside that minimal scope, with `new System.Net.NetworkCredential(String.Empty, secureToken).Password` — do not persist the plaintext to a wider-scoped `String` variable.
+- **If the activity genuinely cannot accept `SecureString`**, exclude it from the rule deliberately: Project Settings → **Workflow Analyzer** → add the activity namespace to the rule's **Excluded Activities** field (or lower ST-SEC-009 from Error to Warning if policy allows). This is a conscious, scoped exception — not a blanket disable.
+- Re-run the analyzer to confirm the finding clears.

package/skills/uipath-troubleshoot/references/activity-packages/web-activities/summary.md

@@ -11,3 +11,8 @@
 | Deserialize — Malformed JSON / XML Input | High | `DeserializeJson` / `DeserializeJsonArray` throw `Newtonsoft.Json.JsonReaderException` and `DeserializeXml` throws `System.Xml.XmlException` when the input string is not valid JSON/XML (HTML error page, empty/partial body, wrong encoding, object-vs-array). The `line`/`position` localizes the defect. **Most common cause: an upstream `HttpClient`/`NetHttpRequest` returned a non-payload body** — diagnose the HTTP call. | [deserialize-malformed-input.md](./playbooks/deserialize-malformed-input.md) |
 | Deserialize JSON — Type Mismatch | Medium | `DeserializeJson<T>` throws `Newtonsoft.Json.JsonSerializationException` when well-formed JSON does not fit the target type `T` (object-vs-array, member type mismatch, schema drift, wrong `T`). The message `Path` names the offending member. | [deserialize-type-mismatch.md](./playbooks/deserialize-type-mismatch.md) |
 | Deserialize — Null / Empty Input | High | Input string is null/empty. `DeserializeJson` guards it → `System.ArgumentNullException (Parameter 'JSON string')`; `DeserializeJsonArray` has no guard → `System.NullReferenceException`. Usually an unassigned variable or a null upstream value. | [deserialize-null-input.md](./playbooks/deserialize-null-input.md) |
+| HTTP Request — 401 Unauthorized / 403 Forbidden | Medium | A request is answered `(401) Unauthorized` or `(403) Forbidden`. The server authenticated-checked the call — an auth problem, not transport/media-type/proxy. `401` = not authenticated (missing/expired token, or a malformed `Authorization` header — classically the **bare token instead of `"Bearer " + token`**, or wrong scheme). `403` = authenticated but lacks scope/role/permission (or key quota / IP restriction). Legacy → `WebException`; `NetHttpRequest` → returned response. | [http-request-auth-401-403.md](./playbooks/http-request-auth-401-403.md) |
+| HTTP Request — Payload Rejected (400 / 415) | Medium | A `POST`/`PUT` with a body or file is answered `(400) Bad Request` or `(415) Unsupported Media Type`. The request reached the server and was rejected on **media type / payload shape** — `Content-Type` vs body mismatch (`BodyFormat` defaults to `application/xml`), or an attachment sent with the wrong shape (`multipart/form-data` vs JSON; Add Attachment is `POST`/`PUT`-only). NOT auth/path/transport. Legacy → `WebException`; `NetHttpRequest` → returned response. | [http-request-content-type-rejected.md](./playbooks/http-request-content-type-rejected.md) |
+| HTTP Request — Blocked by Proxy (StatusCode 0 / 407) | Medium | External call returns `StatusCode 0` / `NULL`, `(407) Proxy Authentication Required`, or a timeout — **only from the robot/server**, not the developer machine. No HTTP response reached the activity: the environment's corporate proxy is not in the request path (Web activities expose no proxy property; system proxy not picked up under a service/unattended account). Distinct from a DNS/TLS `WebException`. | [http-request-proxy-blocked.md](./playbooks/http-request-proxy-blocked.md) |
+| Web — Package / Studio Version Mismatch (design-time) | Medium | **Design-time** only: opening/validating the project or the **HTTP Request wizard** throws `System.MissingMethodException: Method not found: 'Void UiPath.Web.Activities...'`, or HTTP Request shows as a missing activity. `UiPath.WebAPI.Activities` version is incompatible with the installed Studio, or skewed against `UiPath.System.Activities`. Assembly loaded but a member is absent → align packages in Manage Packages. NOT the runtime "Could not load file or assembly" fault. | [package-version-mismatch.md](./playbooks/package-version-mismatch.md) |
+| Web — ST-SEC-009 SecureString Misusage (design-time) | Medium | **Design-time** Workflow Analyzer finding, not a runtime fault: `ST-SEC-009` flags a `SecureString`→`String` conversion feeding an HTTP header (API key/token), or a `SecureString` scoped too widely. Fix = Get Credential + minimal scope + secure storage (Orchestrator credential asset); convert at point of use only; optionally exclude the activity namespace from the rule. Upgrading the WebAPI package does **not** fix it. | [securestring-misuse-analyzer.md](./playbooks/securestring-misuse-analyzer.md) |

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/connector-null-reference.md

@@ -28,7 +28,20 @@ NRE is opaque — the goal is to find **which reference was null** and why.
 
 ## Resolution
 
-- **If the operation can return no rows:** guard the output before use — check for null / empty before the `For Each` or dereference.
+**When the stack frame shows a `For Each` over a connector `*_List` / query output, the missing
+null/empty guard IS the fix — lead with it.** That stack signature already establishes what was null
+and where it was dereferenced; the remaining bullets are alternatives to check only if it does not
+apply. Give the concrete guard, not the idea of one:
+
+```vb
+If result IsNot Nothing AndAlso result.Count > 0
+```
+
+so a query returning no records skips the loop instead of faulting. Listing output-mapping, stale
+bindings and null inputs as co-equal possibilities alongside it, without committing to the guard, is
+an incomplete answer — the user is left without a change to make.
+
+- **If the operation can return no rows:** guard the output before use — check for null / empty before the `For Each` or dereference, using the pattern above.
 - **If the output is unmapped:** assign the connector activity's result to the variable the downstream activity reads.
 - **If a required input was null:** populate it (or guard upstream) so the operation returns a result.
 - **If a stale binding after republish:** re-bind the connector activity's output to the current entity type and republish.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/connector-runtime-exception.md

@@ -19,6 +19,8 @@ Which activities produce this:
 - **ConnectorActivity** — DAP-RT-1002, DAP-RT-1003, DAP-RT-1101.
 - **ConnectorTriggerActivity** — DAP-RT-1052 (and DAP-RT-1002 if the trigger has no connection).
 
+> Same `RuntimeException` class, different failure: a **`Response content too large`** message (the provider call succeeded but the response exceeded the 8 MB JSON limit — no provider status) is NOT one of these codes → [response-content-too-large.md](./response-content-too-large.md).
+
 What can cause it:
 - **1002:** activity dropped its connection binding (common after copy/paste between projects, or a deleted asset feeding `ConnectionId`).
 - **1003:** an input argument is empty because an upstream variable was null, or a mandatory field was left unmapped.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/is-activities-prerelease-not-found.md

@@ -0,0 +1,39 @@
+---
+confidence: medium
+---
+
+# IS Activities Package — Prerelease/Beta Version Not Found (design-time feed resolution)
+
+> **Design-time (Studio) failure — not a runtime fault.** The `UiPath.IntegrationService.Activities` package fails to restore/resolve in Studio because the project pins a **prerelease/beta** version that is not present in the configured feed. Integration Service connector activities disappear or error on the canvas; the project will not compile. NOT a job/execution failure → for runtime connector faults (`DAP-…`, `Response content too large`, connection errors) see the runtime playbooks in this folder.
+
+## Context
+
+What this looks like:
+- Studio dependency restore / package manager fails on **`UiPath.IntegrationService.Activities`** with a version that has a prerelease suffix, e.g. `1.16.0-beta.20250603.1`, `1.15.0-beta.20250425.1`
+- Verbatim message forms: **`Unable to find package 'UiPath.IntegrationService.Activities' with version '<X.Y.Z-beta...>'`**, `Failed to resolve dependencies`, `Could not find package ... in the configured feed`
+- Every Integration Service activity in the project shows as missing/unavailable; the workflow will not validate or compile
+- Often appears right after **opening** a project or after a Studio/connector upgrade
+
+What can cause it:
+- The `UiPath.IntegrationService.Activities` package is the **unified dynamic IS activities package** (Studio Desktop 2023.10+). It **auto-upgrades to the latest connector version when a workflow is opened** — which can pull a **prerelease/beta** reference into `project.json`.
+- The configured feed does not serve that prerelease build. The **UiPath-Official** feed exposes stable versions (e.g. `1.14.0`, `1.15.0`); the beta build is not there.
+- **Primary root cause in practice:** Studio is connected to the **wrong / non-official cloud environment**, so it resolves against a feed that does not front the official package versions. Connecting to the official `https://cloud.uipath.com/` restores resolution of the correct stable versions.
+- Prerelease packages are only visible when **"Include prerelease"** is enabled and the feed actually hosts them; a stable-only feed cannot satisfy a `-beta` pin.
+
+What to look for:
+- The `-beta`/prerelease suffix on the `UiPath.IntegrationService.Activities` version in `project.json` `dependencies`
+- Which cloud environment Studio is signed in to (official vs a staging/custom org)
+- Whether UiPath-Official is in the enabled package sources, and whether the nearest **stable** version exists there
+
+## Investigation
+
+1. **Read `project.json` `dependencies`** — confirm the pinned `UiPath.IntegrationService.Activities` version and whether it carries a prerelease (`-beta…`) suffix.
+2. **Check the signed-in cloud environment** — is Studio connected to the official `https://cloud.uipath.com/` org, or a staging/custom environment whose feed does not front official packages?
+3. **Check package sources** — is **UiPath-Official** enabled? In Manage Packages, does a **stable** `UiPath.IntegrationService.Activities` version exist while the pinned `-beta` one does not?
+
+## Resolution
+
+- **Connect Studio to the official UiPath cloud environment** (`https://cloud.uipath.com/`). This is the primary fix — the official environment fronts the feed that serves the correct package versions, and resolution succeeds without touching the pin.
+- **Pin a stable version:** in Manage Packages, switch to the **UiPath-Official** feed, disable "Include prerelease", and select the latest **stable** `UiPath.IntegrationService.Activities` (e.g. `1.15.0`) instead of the `-beta` build. Update `project.json` and restore.
+- **Prevent the auto-upgrade re-pinning a beta** — after downgrading, verify the project does not re-pull the prerelease on next open; keep "Include prerelease" off unless a beta is explicitly required.
+- Do not add the beta build to a custom feed to force resolution unless a prerelease is genuinely required — align to a stable version on the official feed instead.

package/skills/uipath-troubleshoot/references/products/integration-service/playbooks/response-content-too-large.md

@@ -0,0 +1,41 @@
+---
+confidence: high
+---
+
+# Response Content Too Large (8 MB JSON limit)
+
+> **Fault bucket: 👤 A — Customer-resolvable.** A payload-sizing problem on the customer's side: the connector operation asked the provider for more data than Integration Service will carry in a single JSON response. Not an IS defect and not a provider outage — the fix is narrowing the query or moving file bytes out of the JSON payload. Lead with: "This is a response-size issue on your side — the connector returned more than the 8 MB JSON limit. Narrow the query or pass files outside JSON." See [dap-error-codes-reference.md](../dap-error-codes-reference.md#fault-ownership--the-two-bucket-decision).
+
+## Context
+
+What this looks like:
+- Verbatim message **`Response content too large`** in the job log / activity error
+- Thrown by `UiPath.IntegrationService.Activities.Runtime.Exceptions.RuntimeException` on a `ConnectorActivity` (a list/search/get operation, or a download that returns file bytes)
+- The connection is healthy and the provider call **succeeded** — the failure is IS refusing to marshal the oversized response, not a provider error. No `ProviderErrorCode` / provider status is present.
+- Can also fire on a **`ConnectorTriggerActivity`** — the 8 MB ceiling applies to trigger event payloads too.
+
+What can cause it:
+- Integration Service enforces an **8 MB limit for data in JSON format**. A list/search/get returned more rows/fields than fit — usually an unbounded query (no **Max records**, no filter) against a large object.
+- The 8 MB JSON limit **includes Base64-encoded files carried inside the JSON body** — downloading a file as an inline Base64 field blows the budget fast. Files handled **outside** JSON have a separate **1 GB** limit.
+- A trigger's event payload exceeded 8 MB.
+
+What to look for:
+- The `Response content too large` string — this is the decisive signature; do not confuse with `DAP-RT-1101` (a *provider* error with a status code) — here the provider returned data successfully and IS rejected the size.
+- Which operation: a **list/search** (row-count problem → filter/Max records) vs a **download/get file** (Base64-in-JSON problem → pass outside JSON).
+- Whether a **Max records** input and query filter are set on the activity (absence points straight at an unbounded pull).
+
+> Shares the `RuntimeException` class with [connector-runtime-exception.md](./connector-runtime-exception.md), but that page covers binding/input/provider `DAP-RT-` codes with a provider status. **This page is only for the `Response content too large` message** (no provider status, size-limit breach). NOT for a provider `BadRequest`/`NotFound` (`DAP-RT-1101`) → [connector-runtime-exception.md](./connector-runtime-exception.md) / [request-failed.md](./request-failed.md).
+
+## Investigation
+
+1. **Confirm the signature** — the log carries `Response content too large`, no `ProviderErrorCode` / provider HTTP status. If a provider status IS present, this is a provider error, not a size breach → [request-failed.md](./request-failed.md).
+2. **Identify the failing operation and connector** — read the connection resource file if source is available (see "Connection Resource File" in [overview.md](../overview.md)) to get `connectorKey`; note whether the activity is a list/search/get vs a file download, and whether it feeds a trigger.
+3. `uip is resources describe <connector-key> <object-name>` — check whether the operation exposes **Max records** / paging / filter inputs, and whether the object can return file/binary fields.
+4. **Inspect the activity inputs in the workflow source** — is **Max records** set? Is there a query filter? Is a file being requested as an inline (Base64) field rather than a file output?
+
+## Resolution
+
+- **List/search returning too many rows:** set the activity's **Max records** to a bounded value and add a query filter (date range, status, key) so the response stays under 8 MB. Page through large result sets in batches instead of pulling everything at once.
+- **Download/get returning file bytes inline:** stop carrying the file inside the JSON body. Use the connector's file-handling path (a file/attachment output handled outside JSON) so the 1 GB out-of-JSON limit applies instead of the 8 MB JSON limit.
+- **Trigger payload over 8 MB:** narrow the trigger's object/fields or filter the event so its payload fits; move any large file content out of the event body.
+- If the operation genuinely must return more than 8 MB of structured JSON and offers no paging/filter, that is a connector-capability limit — split the work into smaller queries; do not treat it as a workflow bug.

package/skills/uipath-troubleshoot/references/products/integration-service/summary.md

@@ -53,6 +53,15 @@ Keyed on the Maestro IntSvc code (`102002`…) or the user-facing message. Same
 | Operation Failed | Medium | IS activity returns error during execution — bad request, unsupported method, or input validation | [operation-failed.md](./playbooks/operation-failed.md) |
 | Connector Activity — GeneralException (DAP-GE) | High | `UiPath.IntegrationService.Activities.Runtime.Exceptions.GeneralException` with `DAP-GE-3000` (`Failed to retrieve connection …` — invalid/no-access, `Connections.View` permission, or Bad Gateway) or `DAP-GE-3005` (`Connection is disabled. Please enable the connection to continue.`). Connection-resolution failure in ConnectorActivity / ConnectorHttpActivity / ConnectorTriggerActivity. | [connector-general-exception.md](./playbooks/connector-general-exception.md) |
 | Connector Activity — RuntimeException (DAP-RT) | High | `UiPath.IntegrationService.Activities.Runtime.Exceptions.RuntimeException` with `DAP-RT-1002` (`Connection ID is empty.`), `DAP-RT-1003` (`<field> field is required.`), `DAP-RT-1052` (`Trigger activity could not find any matches.`), or `DAP-RT-1101` (`Status code: BadRequest./NotFound.`). Binding/input/trigger/operation failure in ConnectorActivity / ConnectorTriggerActivity. | [connector-runtime-exception.md](./playbooks/connector-runtime-exception.md) |
+| Connector Activity — Response Content Too Large | High | `UiPath.IntegrationService.Activities.Runtime.Exceptions.RuntimeException` with verbatim message `Response content too large`. Provider call succeeded but the response exceeded the **8 MB JSON limit** (includes Base64 files in JSON; files outside JSON cap at 1 GB). Applies to `ConnectorActivity` list/search/get and `ConnectorTriggerActivity` event payloads. Customer-resolvable: set **Max records** + query filter, or pass files outside JSON. | [response-content-too-large.md](./playbooks/response-content-too-large.md) |
 | Connector Activity — RemoteException (IPC) | Medium | `UiPath.Ipc.RemoteException` / `UiPath.CoreIpc.RemoteException` — out-of-process connector executor fault crossing the IPC boundary (no DAP code). Match on the **unwrapped inner message**: token/auth, transport, or downstream HTTP (404/502/503). Disambiguate from non-connector RemoteExceptions. | [connector-remote-exception.md](./playbooks/connector-remote-exception.md) |
 | Connector Activity — NullReferenceException | Medium | `System.NullReferenceException` on/after a connector activity — typically enumerating a null connector output (`ForEach` over `SWEntities.*_List`), an unmapped output, or a null required input. | [connector-null-reference.md](./playbooks/connector-null-reference.md) |
 | Connector Activity — AggregateException | Low | `System.AggregateException` on a connector activity — async connector fault(s). The real cause is `InnerExceptions[0]`; unwrap and re-classify. | [connector-aggregate-exception.md](./playbooks/connector-aggregate-exception.md) |
+
+## Design-time (Studio)
+
+Keyed on Studio package-restore / dependency errors — these fire while building or opening a project, not at runtime.
+
+| Issue | Confidence | Description | Playbook |
+|-------|:---:|-------------|----------|
+| IS Activities Prerelease/Beta Not Found | Medium | Studio dependency restore fails on `UiPath.IntegrationService.Activities` pinned to a prerelease/`-beta` version not served by the configured feed (`Unable to find package … version <X.Y.Z-beta…>`); IS activities show missing/invalid. The unified package auto-upgrades on open and can pull a prerelease; fix = connect to the official cloud env / UiPath-Official feed and pin a stable version. | [is-activities-prerelease-not-found.md](./playbooks/is-activities-prerelease-not-found.md) |

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/console-conflict-login-to-console.md

@@ -0,0 +1,40 @@
+---
+confidence: medium
+---
+
+# Could Not Start Executor — Interactive Job Using the Console (HD + Login to Console)
+
+## Context
+
+An unattended job faults at start with:
+
+```
+Another interactive job is using the machine's console. Only one interactive job can use the console at a time.
+```
+
+What this looks like:
+- Job state: Faulted at start; a **concurrent** interactive job on the same host is already attached to the console.
+- The affected robots are **High-Density (HD)** — multiple robot users on one machine — configured with **"Login to Console = True."**
+
+What causes it:
+- With **Login to Console = True**, the Robot Service attaches the job to the machine's **single physical console session** instead of creating its own RDP/virtual session. A Windows host has **exactly one console session**, so only one console-attached interactive job can run at a time. On an HD robot (designed for *many* concurrent sessions), forcing every job onto the console serializes them to one — the second concurrent job is refused.
+- Per UiPath guidance, **Login to Console is not recommended for HD robots** precisely because there can only be one active console session at a time.
+- This is distinct from **Foreground Process Already Running** ([foreground-already-running.md](./foreground-already-running.md) — Assistant-started foreground concurrency on one user) and from **Workstation In Use** ([workstation-in-use-machine-slots.md](./workstation-in-use-machine-slots.md) — OS session capacity vs over-provisioned slots).
+
+What to look for:
+- The message names the **console** specifically (not "workstation," not "foreground process").
+- The host runs **HD robots** (multiple robot users / several slots) — check the machine template.
+- **Login to Console = True** on the robot user's execution settings (Tenant → Users → user → Access Rules → Advanced Robot Options; the setting may not be exposed via `uip`).
+
+## Investigation
+
+1. **Get the faulted job:** `uip or jobs get <job-key> --output json` → confirm the `Another interactive job is using the machine's console` message and the `HostMachineName`.
+2. **Confirm HD context:** `uip or machines list --all-fields --output json` → the host template has multiple robot users / several slots (HD), not a single dedicated unattended slot.
+3. **Correlate concurrency:** `uip or jobs list --folder-key <key> --output json` → a second interactive job was Running on the same host in the same window.
+4. **Confirm the setting:** check **Login to Console** for the robot user (Tenant → Users → user → Advanced Robot Options). `True` on an HD robot is the root cause.
+
+## Resolution
+
+- **Disable "Login to Console"** for the HD robot user(s) on that host, so each job gets its own RDP/virtual session instead of competing for the single console session. This is the recommended configuration for HD robots.
+- After disabling, re-run — concurrent interactive jobs will each seat in their own session up to the licensed slot count.
+- Do not treat this as a credential or transient issue — rerunning with Login to Console still True just re-hits the single-console limit whenever two jobs overlap.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/credential-store-unavailable.md

@@ -0,0 +1,42 @@
+---
+confidence: medium
+---
+
+# Credential Store Unavailable — Cannot Retrieve Robot Credential
+
+## Context
+
+A job fails to start because Orchestrator cannot **retrieve** the robot credential from its credential store — the store backend itself is unreachable or misconfigured. This is distinct from a wrong/expired password (see `robot-credentials.md` / `job-faulted-logon-failure.md`): here the credential is never obtained at all, so no Windows logon is even attempted.
+
+What this looks like:
+- `Unable to retrieve credentials from Orchestrator Database credential store. Please check your connection settings and ensure the Orchestrator Database service is running.`
+- Or, for an external store: errors naming CyberArk / Azure Key Vault / HashiCorp Vault (vault unreachable, secret not found, or access denied)
+- Job faults at/near start with a credential-**retrieval** error, not a `Logon failed` / `0x0000052E` code
+- Often affects **every** robot/asset bound to the same store simultaneously (store-wide, not one user)
+
+What can cause it (branches):
+1. **Orchestrator Database store unreachable** — the Orchestrator SQL database (which backs the default "Orchestrator Database" credential store) is down, or the connection string / network path to it is broken.
+2. **External vault unreachable / misconfigured** — the CyberArk / Azure Key Vault / HashiCorp store's endpoint, credentials, or network path is wrong or the vault is down.
+3. **Secret missing / access denied in the store** — the credential record was deleted/renamed in the store, or Orchestrator's service principal lost read permission.
+4. **Store misconfiguration** — the credential store definition in Orchestrator points at the wrong instance/path after a migration or config change.
+
+## Investigation
+
+1. Get the failing job and confirm the signature (retrieval, not logon):
+   `uip or jobs get <job-key> --output json` — `Info` names the credential store / retrieval, with no `Logon failed` code.
+2. Read logs for the store-side error detail:
+   `uip or jobs logs <job-key> --level Error --output json` — which store (Orchestrator DB vs external vault), and the underlying reason (connection, not-found, access-denied).
+3. Establish scope — is it store-wide?
+   `uip or jobs list --state Faulted --output json` — if many robots/processes bound to the same store fail at once, the store backend is the problem (branch 1/2), not one credential.
+4. Identify which credential store the robot/asset uses (Orchestrator → Credentials/Assets → the robot user or credential asset → Credential Store). Confirm the store type (Orchestrator Database vs CyberArk/AKV/HashiCorp).
+
+## Resolution
+
+- **Branch 1 — Orchestrator Database store unreachable:** verify the Orchestrator SQL database service is running and reachable from Orchestrator (connection string, network, firewall). Restore DB connectivity, then rerun. (This is an Orchestrator-infrastructure dependency — see `overview.md` § Dependencies.)
+- **Branch 2 — external vault unreachable/misconfigured:** check the credential store definition (endpoint URL, app/credential, network reachability) and that the vault service is up. Use Orchestrator's **Test** on the credential store to confirm connectivity, fix the config, rerun.
+- **Branch 3 — secret missing / access denied:** confirm the credential exists in the store under the expected name and that Orchestrator's identity has read permission; re-create/re-grant as needed.
+- **Branch 4 — store misconfiguration after a change:** repoint the credential store to the correct instance/path; re-test.
+
+Prevention:
+- Monitor the credential store backend (SQL DB / vault) health and alert on retrieval failures — store outages are store-wide.
+- After any store or DB migration, run the store's **Test** and a canary job before re-enabling triggers.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/executor-start-transient-rerun.md

@@ -0,0 +1,49 @@
+---
+confidence: medium
+---
+
+# Executor Start / Session — Transient Failure (rerun-class)
+
+## Context
+
+An unattended job faults at (or near) executor start with a **transient session/infrastructure** error — a one-off blip rather than a persistent config, credential, or license fault. Signatures in this class:
+
+```
+Job faulted due to service shutdown or disconnect.
+Job faulted due to service shutdown.
+Could not start executor. Rdp connection failed: Message: The connection transport layer failed., Last error: 131085
+Could not start executor. Rdp connection failed: Message: The disconnection was initiated by the user logging off their session on the server. Last error: 65548
+Could not start executor. A specified logon session does not exist. It may already have been terminated. (0x80070520)
+Could not start executor. User is running another job. Waiting for the job to finish timed out.
+The job was transitioned to a faulted state as a result of a cleanup action for jobs in Terminating state.
+```
+
+What this looks like:
+- Faulted at/near start (or mid-run for the service-shutdown/disconnect case), with a message pointing at a **session/transport/service** event, **not** a Windows logon-failure code, a slot/console message, or a licensing quota.
+- Often **intermittent** — earlier and later jobs on the same machine/user succeed.
+
+What causes it (all transient, shared fix = rerun):
+- **Robot service shutdown / disconnect** — the Robot service restarted or lost its Orchestrator connection while the job was starting or running.
+- **RDP transport drop (`131085`)** — the session's transport layer failed mid-handshake.
+- **User logged off the session (`65548`)** — a human logged off the session the robot was using.
+- **Stale logon session (`0x80070520`)** — the session Windows was going to use was already terminated.
+- **Waiting for prior job timed out** — the user was still running another job and the wait window elapsed.
+- **Terminating-state cleanup** — the robot went **offline** while the job was Terminating, so Orchestrator's cleanup transitioned it to Faulted.
+
+What to look for:
+- The message matches one of the signatures above and carries **no** persistent-fault marker (no `Logon failed` / `0x000005..` code → not [job-faulted-logon-failure.md](./job-faulted-logon-failure.md); no `Creating user session timed out` → not [job-faulted-session-timeout.md](./job-faulted-session-timeout.md); no `workstation is in use` / `console` → not the slots/console playbooks; no quota message → not [serverless-license-quota.md](./serverless-license-quota.md)).
+- **Intermittency** across recent jobs on the same host/user — the strongest signal that it is transient.
+
+## Investigation
+
+1. **Get the faulted job:** `uip or jobs get <job-key> --output json` → capture the exact message and confirm it matches a rerun-class signature (and carries none of the persistent-fault markers above).
+2. **Check intermittency:** `uip or jobs list --folder-key <key> --output json` → do other recent jobs on the same machine/user succeed? Mixed success/failure ⇒ transient.
+3. **Rule out the persistent siblings** — scan the message for a logon code / session-timeout / slots / console / quota string. If present, route to that specific playbook instead of rerunning.
+4. **(Recurring only) note the Robot version** — `uip or machines list --all-fields --output json`; several of these are addressed in newer Robot builds.
+
+## Resolution
+
+- **Rerun the job.** These are transient session/service events; a fresh run on a healthy host typically succeeds.
+- **If it recurs on a specific host/version:** update the Robot to the latest version (several of these signatures are fixed in newer builds) and investigate host stability — RDP/network reliability, robot-to-Orchestrator connectivity, and session hygiene (humans logging off sessions the robot uses, service restarts).
+- **Terminating-cleanup case:** confirm the robot's connectivity/uptime — the job was cleaned up because the robot went offline; restore the host and rerun.
+- **Confirm the signature before a blind rerun.** A persistent logon/credential/license fault will just re-fail — only rerun once the message is confirmed to be in this transient class.