fix(cli): report a job's real exit code and stop claiming stops [PC-4873]

[robert-ursu]

Draft. First PR of the job stop / exit code stack (PC-4873). Re-cut on main @ 7bd1425 (2.14.25). The old async-dispatch and result-push content is gone: #1883 and #1906 (logs and result over IPythonJobApi) superseded it. The parts that were still missing on main are what this PR keeps.

Stack: this PR → #1842 (real cooperative stop over IPC and HTTP) → hdens handler PRs that act on the stop verdict.

Why

A failed job running inside uipath server was reported as a success, on both transports:

1. ConsoleLogger.error ends in click.get_current_context().exit(1). Under standalone_mode=False click returns that code instead of raising (click/core.py, except Exit). _run_command_isolated took the return value as the job's result and hard-coded ExitCode: 0. Every console.error path (runtime errors, unexpected exceptions, bad --simulation) came back as exit code 0.
2. The HTTP /jobs/{key}/start reply had no exitCode. The .NET PythonRuntimeClient reads exitCode into an int and treats a missing one as 0, so every HTTP 200 counted as a success, even when the body said success: false.

The handler usually overrides the exit code with the status in output.json or the IPC result. The exit code decides the outcome when neither exists: failures before or outside UiPathRuntimeContext, and crashes.

What

• _server_core: an int returned by cmd.main is the exit code. run, debug and eval never return an int of their own.
• HTTP start reply: exitCode is added to every response. An unchanged handler becomes correct against this runtime with no .NET change.
• IPC StopJob returns False and logs a warning. It used to log "(no-op)" and return True, which claimed a stop that never happened. feat(cli): really stop a job that uipath server is running [PC-4873] #1842 replaces this with a real stop.
• _job_api: a result status the sink does not know is reported as Faulted, not Successful. "stopped" maps to the wire's Stopped (4), which the handler already accepts.
• uipath run / uipath eval: entrypoint or eval-set discovery failure exits 1 instead of 0.

Compatibility

• HTTP: additive field.
• IPC: StopJob's wire shape is unchanged. Only the value changes, and today's handler ignores it.
• CLI: discovery failure now exits non-zero, for interactive users too.
• Version 2.14.25 → 2.14.26.

Testing

• uv run pytest tests/cli: 1502 passed, 1 skipped, 1 xfailed.
• ruff check, ruff format --check and mypy are clean.
• New tests:
  • a real click command that calls ConsoleLogger.error reports exit code 1 through the job core;
  • an HTTP job whose entrypoint raises replies success: false, exitCode: 1;
  • unknown status maps to Faulted, and "stopped" to Stopped.
• Updated tests: StopJob now returns False, and the discovery tests expect exit code 1.

Jira

PC-4873

🤖 Generated with Claude Code

https://claude.ai/code/session_01CFMKm7zHGcptS49z4cnnad

[sonarqubecloud]

Quality Gate failed

Failed conditions
82.6% Coverage on New Code (required ≥ 90%)
B Security Rating on New Code (required ≥ A)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🚨 Heads up: uipath-langchain cross-tests are FAILING 🚨

Your changes may break the uipath-langchain-python integration.

⚠️ These checks are NOT enforced by branch protection rules. Please review the failures before merging.

🔍 Inspect the failed run →