Skip to content

CI: Replace Blue Ocean with pipeline-overview URL - #11796

Merged
Alexey-Rivkin merged 2 commits into
openucx:masterfrom
ntsemah:HPCINFRA-4739
Sep 6, 2026
Merged

Alexey-Rivkin merged 2 commits into
openucx:masterfrom
ntsemah:HPCINFRA-4739

Conversation

@ntsemah

@ntsemah ntsemah commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

What?

Replace GitHub commit status links to point to Jenkins' pipeline-overview page instead of Blue Ocean UI.

Why?

Justification for the PR. If there is an existing issue/bug, please reference it. For
bug fixes, the 'Why?' and 'What?' can be merged into a single item.

How?

It is optional, but for complex PRs, please provide information about the design,
architecture, approach, etc.

@ntsemah

ntsemah commented Aug 19, 2026

Copy link
Copy Markdown
Contributor Author

/build

dpressle
dpressle previously approved these changes Aug 23, 2026
@svc-ucx

svc-ucx commented Aug 23, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-codestyle-oss · commit 4ffd98a5

TL;DR: The Authors Check codestyle stage failed because the PR author Noam Tsemah <ntsemah@nvidia.com> is not listed in the AUTHORS file; add that line (alphabetically, after Nir Wolfer) and amend/push to fix.

Full analysis

Summary: Stage Authors Check (node 83) in UCX-OSS/ucx-codestyle-oss #3 exited with code 1 — missing AUTHORS entry for the commit author.

Root cause: The CI authors check scans the commit range [REDACTED:Hex High Entropy String]..[REDACTED:Hex High Entropy String] and requires every committer identity to be present in the repo's AUTHORS file. The commit 4ffd98a5 is authored by Noam Tsemah <ntsemah@nvidia.com>, which does not appear in AUTHORS (confirmed: the file jumps from Nir Wolfer <nwolfer@nvidia.com> on line 90 straight to Ofir Farjon <ofarjon@nvidia.com> on line 91). The check even printed the exact patch it expects. This is not an infrastructure or timing failure — the log shows the check completing normally in 1.4 s. The downstream Codespell and Ctags stages never ran because the parallel branch aborted (hudson.AbortException: parallel task failed).

Implicated commit: [REDACTED:Hex High Entropy String] — Noam Tsemah ntsemah@nvidia.com (branch HPCINFRA-4739, PR #11796)

File: AUTHORS:90-91

Suggested fix: Add the author to AUTHORS in the existing alphabetical position, exactly as the check suggested:

 Nir Wolfer <nwolfer@nvidia.com>
+Noam Tsemah <ntsemah@nvidia.com>
 Ofir Farjon <ofarjon@nvidia.com>

Include this change in PR #11796 (either as part of commit 4ffd98a5 via git commit --amend or as an additional commit) and push. Also verify the git user.name/user.email used for the commit matches the AUTHORS entry byte-for-byte, since the check compares the full Name <email> string — a mismatch in spelling or a different email (e.g. a personal vs. corporate address) will keep failing even after the line is added. After this passes, the Codespell and Ctags stages will run for the first time on this PR, so expect them to report separately.

Related: PR #11796 (this PR). No existing issue found for this failure; it is a per-PR onboarding step rather than a recurring CI bug.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id adfb2747-d90c-4207-9d86-d4cadcf62650 in the triage console for the audit trail.

@svc-ucx

svc-ucx commented Aug 23, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-build-static-oss · commit 4ffd98a5

TL;DR: The x86_64/centos7-ib "Build Static" stage failed because az_module_load dev/libnl could not find the module — module avail aborts on the centos7 image due to a stale/dangling hpcx-2.51 entry in the shared /hpc/local/etc/modulefiles NFS tree, so nothing from that path is listed even though dev/libnl exists. This is an infra/CI-harness issue unrelated to PR #11796; fix the broken modulefiles entry and/or make az_module_load fall back to a direct modulefile existence check.

Full analysis

Summary: buildlib/tools/build_static.sh aborted at build_static() → az_module_load dev/libnl (exit code 1) in the centos7-ib axis; the ubuntu2004-mofed5.0 axis of the same job passed.

Root cause: Evidence from stage 80/37 log:

  • 5 retries of module avail -t | grep -q '^dev/libnl$' all fail.
  • The diagnostic module avail then prints:
    ModuleCmd_Avail.c(804):ERROR:64: Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found
    ModuleCmd_Avail.c(529):ERROR:57: Error while reading directory '/hpc/local/etc/modulefiles'
    and only lists /usr/share/Modules/modulefiles (dot, module-git, …).
  • Yet ls -l /hpc/local/etc/modulefiles/dev/libnl succeeds (-rw-r--r-- 1 root root 706 Feb 25 12:41), proving the NFS mount and the modulefile are present.

So the classic Environment Modules 3.2.x modulecmd used in the centos7 image aborts the entire scan of /hpc/local/etc/modulefiles when it hits the dangling hpcx-2.51 entry (a symlink/dir pointing at a removed HPC-X version). Because az_module_load decides availability solely from module avail -t output, it returns 1, and build_static.sh (#!/bin/bash -eEx) fails the stage. The retry/ls /hpc/local automount workaround cannot help — this is not an automount race, it is a permanently broken directory entry. Newer Tcl-based Modules on ubuntu2004 tolerates it, which is why only the centos7 axis failed.

Implicated commit: unknown — not a code regression from 4ffd98a5 / PR #11796 ("CI: Replace Blue Ocean with pipeline-overview URL"). The failing helper az_module_load was last touched by unrelated commits (e.g. 5c4ddb1a, Yaser Afshar; 925746b4, Alexey Rivkin); the trigger is the state of the shared /hpc/local/etc/modulefiles tree.

File: buildlib/az-helpers.sh:118 (the until module avail -t 2>&1 | grep -q "^$module\$" check), reached from buildlib/tools/build_static.sh:17

Suggested fix:

  1. Infra (real fix): remove or repair the dangling hpcx-2.51 entry under /hpc/local/etc/modulefiles so modulecmd avail no longer errors out on centos7 nodes.
  2. Harden the helper so a single bad modulefiles entry can't fail all builds — check the modulefile directly before giving up, e.g. in az_module_load:
    # after the retry loop, before returning 1
    for p in ${MODULEPATH//:/ }; do
        if [ -f "$p/$module" ] || [ -d "$p/$module" ]; then
            echo "Found $module in $p despite 'module avail' failure; loading directly"
            module load "$module" && return 0
        fi
    done
    (and keep the existing warning/return 1 path only if that also fails).
  3. Re-run the job once the modulefiles tree is fixed; no source change is needed in the PR.

Security note: the stage log dumps the full environment via env, which prints the githubData payload containing an Artifactory basic-auth credential in plaintext. Rotate that Artifactory credential and stop dumping githubData/env unmasked in prepare_build.

Related: none found (searched issues/PRs for az_module_load / module avail failures — no matches).

@svc-ucx

svc-ucx commented Aug 23, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-coverity-oss · commit 4ffd98a5

TL;DR: All Coverity stages failed because az_module_load tools/cov-2019.12 could not find the module: on this Jenkins agent module avail aborts enumerating /hpc/local/etc/modulefiles due to a stale/broken hpcx-2.51 entry, so the existence check never matches even though the modulefile is present. Fix the broken modulefiles entry on the agent and make az_module_load stop relying on a full module avail listing.

Full analysis

Summary: UCX-OSS/ucx-coverity-oss #3 — both x86_64/cov/release and x86_64/cov/devel Coverity stages exit 1 in modules_for_coverity → az_module_load tools/cov-2019.12 ("Module tools/cov-2019.12 not found" after 5 retries).

Root cause: Environment/agent issue, not a code regression in the commit under test. The stage log shows:

  • ModuleCmd_Avail.c(804):ERROR:64: Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found
  • ModuleCmd_Avail.c(529):ERROR:57: Error while reading directory '/hpc/local/etc/modulefiles'

The (old, 3.x) Environment Modules on this Jenkins node aborts the directory walk of /hpc/local/etc/modulefiles when it hits the dangling hpcx-2.51 entry, so module avail -t lists only /usr/share/Modules/modulefiles (dot, module-git, …). Meanwhile the very next line proves the module file is there and readable: -rw-r--r-- 1 root root 285 ... /hpc/local/etc/modulefiles/tools/cov-2019.12. So az_module_load's existence test (module avail -t 2>&1 | grep -q "^$module$", buildlib/az-helpers.sh:118) produces a false negative, returns 1, modules_for_coverity propagates non-zero, and the script dies under bash -eE before Coverity ever runs. The retry loop (ls /hpc/local) cannot help because this is not an automount timing issue. This is exposed by the migration of the Coverity job to the OSS Jenkins agents (branch HPCINFRA-4739 / PR #11796) — the Azure agents' newer Modules tolerate the bad entry.

Implicated commit: unknown (no UCX source commit implicated; the last functional change in this area is 5c4ddb1 "BUILD/CI: Add ZE null-driver build and smoke check (#11569)", Yaser Afshar, which reworked az_init_modules, but the failure is the agent's /hpc/local/etc/modulefiles/hpcx-2.51 breakage)

File: buildlib/az-helpers.sh:114-136 (az_module_load), triggered from buildlib/tools/coverity.sh:47-62,131

Suggested fix:

  1. Infra (primary): on the ucx-coverity-oss Jenkins agents, remove/repair the dangling /hpc/local/etc/modulefiles/hpcx-2.51 symlink/dir (or fix its autofs mount), and/or update the agent image to Environment Modules 4/5 which skips unreadable entries instead of aborting the scan.
  2. Harden the helper so a single bad modulefiles entry can't fail every job — query only the requested module and fall back to a direct file/load check, e.g.:
until module avail -t "$module" 2>&1 | grep -q "^${module}\$" ||
      module load "$module" 2>/dev/null; do

or test existence explicitly: for d in ${MODULEPATH//:/ }; do [ -f "$d/$module" ] && break; done. Passing the module name as an argument to module avail restricts the directory traversal to tools/ and avoids the broken top-level entry entirely.
3. Optional: have az_module_load print module avail -t "$module" stderr on failure so this class of infra breakage is obvious immediately.

Related: none found (searched issues/PRs for this signature)

@svc-ucx

svc-ucx commented Aug 23, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-gpu-oss · commit 4ffd98a5

TL;DR: No UCX code failure — all four parallel GPU test workers failed in the "Allocate Environment" stage because their Slurm salloc requests sat queued in partition funk and hit the hard-coded --immediate=600 limit ("Unable to allocate resources: Connection timed out"); this is a cluster-capacity/infra issue, so retry the build and/or make the allocation wait configurable with retries.

Full analysis

Summary: UCX-OSS/ucx-test-gpu-oss #5 failed in stages 141/150/160/178 ("Allocate Environment") on all 4 workers — salloc could not obtain a node in Slurm partition funk within 600 s.

Root cause: Each worker branch runs .ci/scripts/run_slurm_allocation.sh, which invokes via scctl:
salloc -N 1 -p funk --job-name=ucx-ci-w<N>-5 --immediate=600 --time=02:45:00 --no-shell
The log shows the jobs were accepted but never scheduled:

  • 11:59:16 salloc: Pending job allocation 82203 … 12:09:22 salloc: error: Unable to allocate resources: Connection timed out (≈606 s, exactly --immediate=600)
  • Identical pattern for job 82204 (w1), plus w2/w3 — all four branches failed within seconds of each other.

The ~10-minute gap in the log is not a hang in the build: it is salloc legitimately blocking while queued for resources, and the --immediate deadline expiring. The partition funk had no free nodes (4 concurrent single-node requests from the same build also compete with each other). There is no retry around the allocation, so the first timeout aborts the whole parallel stage and the build.

Note also that the build commit 4ffd98a ("CI: Replace Blue Ocean with pipeline-overview URL", Noam Tsemah) only changes a URL string and cannot cause this. Secondary observation: the pipeline_stop cleanup stage logged WARNING: No job ID files found in /mnt/pvc/ because slurm_job_id_file is only written after a successful allocation (line 196), so a partially/late-granted allocation would be leaked with no cleanup path.

Implicated commit: unknown (infrastructure/capacity). Script origin: ffc2138f — Iaroslav Sydoruk, "CI: Add GPU SLURM test pipeline for scctl cluster"

File: .ci/scripts/run_slurm_allocation.sh:115 (SLURM_IMMEDIATE_TIMEOUT=600) and :163 (scctl --raw-errors client connect -- "${SLURM_ALLOCATION_CMD}")

Suggested fix:

  1. Re-trigger the build; check sinfo -p funk / squeue -p funk for node availability or drained nodes before blaming the PR.
  2. Make the wait tolerant: set SLURM_IMMEDIATE_TIMEOUT per-pipeline (e.g. 1800) and/or wrap the scctl ... salloc call in a bounded retry loop (N attempts with backoff) instead of failing on the first timeout.
  3. Distinguish "no resources available" from a real error — on --immediate expiry, fail the stage as NOT_BUILT/aborted (or requeue) rather than FAILURE, so PRs aren't marked broken by cluster contention.
  4. Reduce self-contention: serialize the 4 worker allocations or allocate -N 4 once and split, so the branches don't queue against each other in funk.
  5. Harden cleanup: capture the pending job ID (e.g. from squeue --name=) before the allocation can time out, so pipeline_stop can cancel orphaned/pending Slurm jobs.

Related: PR #11796 (branch HPCINFRA-4739) — no existing issue found for this Slurm allocation timeout; consider opening one to track allocation retry handling.

@svc-ucx

svc-ucx commented Aug 23, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-dl-gpu-oss · commit 4ffd98a5

TL;DR: The Checkout & test stage was killed by Jenkins after ~2h20m, but the job wasn't slow — it hung: the very first UCP client‑server stream API test (-m host -c stream -s 1) produced no output for 2h09m while run_client_server_app blocked forever in an unbounded wait ${client_pid}. Investigate the stream send/recv deadlock introduced by this PR, and add a timeout wrapper in contrib/test_jenkins.sh so hangs fail fast with diagnostics.

Full analysis

Summary: Build #4, stage 160 "Checkout & test" (ABORTED after 8,410 s) — the ucp_client_server stream test deadlocked and the pipeline hit its wall‑clock limit.

Root cause: Timestamp analysis of the stage log shows continuous activity through all am and tag message sizes (each iteration ~16 s apart), then:

  • 12:20:09 — ==== Running UCP client-server with "host" memory type using "stream" API with msg_size={1} ====
  • 12:20:09 — server started, prints server is listening on IP 0.0.0.0 port 10510
  • 12:20:24 — client started: taskset -c 1 ./examples/ucp_client_server -m host -c stream -s 1 -a 127.0.0.1 -p 10510
  • …2 h 09 min of complete silence…
  • 14:29:40 — Sending interrupt signal to process / Killing processes / Timeout has been exceeded

That single gap is ~92 % of the stage runtime, so this is a hang, not insufficient time. Neither process emitted anything after the client launched — the server never printed Waiting for connection.../Server received a connection request, and the client never printed Client: iteration #1. The hang is therefore in the stream‑API path (connection establishment + ucp_stream_send_nbx / ucp_stream_recv_nbx progress loop), on loopback 127.0.0.1, on the aarch64 dl‑gpu image. The identical am and tag cases over the same transport passed seconds earlier in the same build, which isolates the failure to the stream code path rather than the environment or wireup in general.

The reason this consumed the whole job instead of failing is contrib/test_jenkins.sh:201: wait ${client_pid} has no timeout, and there is no per‑app watchdog anywhere in run_client_server_app.

Implicated commit: [REDACTED:Hex High Entropy String] (PR #11796, branch HPCINFRA-4739) is the change under test and the prime suspect — examples/ucp_client_server.c itself is untouched since 1af57d6 (2024‑11‑29, rakhmets), and src/ucp/stream since d65ffe7 (2026‑06‑01, Michal Shalev, "UCP: SGL datatype implementation (#11344)"). The PR diff is not visible from the log, so the exact hanging change cannot be pinned further from evidence.

File: contrib/test_jenkins.sh:201 (unbounded wait, the reason the hang became a wall‑clock kill); hanging operation is examples/ucp_client_server.c:402-434 (send_recv_stream, ucp_stream_send_nbx/ucp_stream_recv_nbx)

Suggested fix:

  1. Do not raise the pipeline time limit — it would just burn 2+ hours again.
  2. Reproduce locally: ./examples/ucp_client_server -m host -c stream -s 1 -p 10510 plus the client with -a 127.0.0.1, and when it hangs capture gdb -p <pid> -batch -ex "thread apply all bt" on both client and server, plus UCX_LOG_LEVEL=debug. That will show whether the block is in wireup/connection establishment or in ucp_worker_progress waiting on a stream request that never completes.
  3. Bisect the PR's commits against the stream case specifically, since am/tag pass — look for changes affecting stream request completion, UCP_STREAM_RECV_FLAG_WAITALL handling, or single‑byte/short‑message protocol selection.
  4. Harden CI so the next hang is diagnosable in minutes: wrap the client/server launches in run_client_server_app with timeout --signal=ABRT 300 ... (ABRT so a core/backtrace is produced), and fail the test on exit code 124/134 instead of blocking on wait.

Related: PR #11796 (the change under test); no existing issue found for a stream client‑server hang — the only near match from a repo search was unrelated (#4353, client/server connection with atomics).

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 7c1266b4-2b67-403a-bda6-d7ccb499aec1 in the triage console for the audit trail.

@ntsemah

ntsemah commented Aug 25, 2026

Copy link
Copy Markdown
Contributor Author

/build

@svc-ucx

svc-ucx commented Aug 25, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-coverity-oss · commit 06972371

TL;DR: Both Coverity stages failed because module avail on the build nodes aborts with "Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found", so az_module_load never sees tools/cov-2019.12 (the modulefile is actually present on disk) — this is a broken shared modulefiles tree on the agents, unrelated to PR #11796; fix the stale hpcx-2.51 entry and make az_module_load stop relying on module avail enumeration.

Full analysis

Summary: x86_64/cov/release and x86_64/cov/devel → Coverity stages (node IDs 62, 80) failed after 5 retries with Module tools/cov-2019.12 cannot be loaded / Step Coverity failed with exit code=1.

Root cause: az_module_load decides whether a module exists by grepping the output of module avail -t. On these agents Environment Modules bails out while enumerating the module path:

ModuleCmd_Avail.c(804):ERROR:64: Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found
ModuleCmd_Avail.c(529):ERROR:57: Error while reading directory '/hpc/local/etc/modulefiles'

Because of the dangling hpcx-2.51 entry (stale symlink / removed HPC-X version referenced from the modulefiles tree), nothing under /hpc/local/etc/modulefiles is listed — module avail only prints /usr/share/Modules/modulefiles. The Coverity modulefile itself is perfectly readable, as the script's own debug output proves:

+ ls -l /hpc/local/etc/modulefiles/tools/cov-2019.12
-rw-r--r-- 1 root root 285 Feb 25 12:41 /hpc/local/etc/modulefiles/tools/cov-2019.12

So this is not an autofs/timing issue (retries and ls /hpc/local cannot help), and it is not caused by the commit under test — PR #11796 only changes a Jenkins URL string. Both parallel stages failed identically on all agents, indicating an environment/infra regression in the shared /hpc/local modulefiles directory.

Implicated commit: unknown — not a source regression; the CI agents' /hpc/local/etc/modulefiles tree is broken. (Closest related code: 5c4ddb1a, Yaser Afshar, last touched buildlib/az-helpers.sh.)

File: buildlib/az-helpers.sh:118 (until module avail -t 2>&1 | grep -q "^$module\$"), used by buildlib/tools/coverity.sh:49

Suggested fix:

  1. Infra (primary): remove/repair the dangling hpcx-2.51 entry under /hpc/local/etc/modulefiles (or restore the missing directory) so modulecmd avail can enumerate the tree again. Verify with module avail -t | grep tools/cov-2019.12 on the coverity agents.
  2. Hardening (in-repo, makes CI immune to one bad modulefile): stop using directory enumeration for the existence check — probe the module directly, e.g.
function az_module_load() {
    module=$1
    retries=5
    until module show "$module" >/dev/null 2>&1; do
        if [ $retries -gt 1 ]; then
            echo "Module $module not found, retrying..."
            ls /hpc/local >/dev/null 2>&1
            sleep 1
        else
            echo "MODULEPATH='${MODULEPATH}'"
            module avail || true
            ls -l /hpc/local/etc/modulefiles/"$module" || true
            azure_log_warning "Module $module cannot be loaded"
            return 1
        fi
        ((retries--))
    done
    module load "$module"
}

module show resolves the modulefile via MODULEPATH lookup instead of listing the whole directory, so an unrelated broken entry no longer masks every module.

Related: PR #11796 (#11796) — the triggering PR, unrelated to the failure; no existing issue found for the hpcx-2.51 modulefiles breakage.

@svc-ucx

svc-ucx commented Aug 25, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-build-static-oss · commit 06972371

TL;DR: The Build Static stage on the centos7-ib container failed because module avail on that image aborts its scan of /hpc/local/etc/modulefiles (dangling hpcx-2.51 entry), so az_module_load dev/libnl never finds the module even though the modulefile exists — fix by cleaning the stale hpcx-2.51 entry on the shared modulefiles NFS share and/or making az_module_load fall back to a direct modulefile existence test instead of parsing module avail.

Full analysis

Summary: UCX-OSS/ucx-build-static-oss #4, stage "Build Static" (x86_64/centos7-ib, node 80) exited 1 after ~19s in buildlib/tools/build_static.sh at az_module_load dev/libnl; the parallel ubuntu2004-mofed5.0 leg passed.

Root cause: Not a UCX code/build failure and not a timeout. The log shows module avail failing on the centos7 image (legacy Environment Modules 3.x):

ModuleCmd_Avail.c(804):ERROR:64: Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found
ModuleCmd_Avail.c(529):ERROR:57: Error while reading directory '/hpc/local/etc/modulefiles'
------------------------ /usr/share/Modules/modulefiles ------------------------

A stale/dangling hpcx-2.51 entry in the shared /hpc/local/etc/modulefiles tree makes modulecmd abort the whole directory scan, so no /hpc/local modules are listed. Consequently module avail -t | grep -q '^dev/libnl$' (az-helpers.sh:118) never matches, the 5 automount retries are useless (this is not an autofs timing problem), and az_module_load returns 1. Because build_static.sh runs with -eE, the whole stage fails. The log itself proves the modulefile is present: ls -l /hpc/local/etc/modulefiles/dev/libnl → -rw-r--r-- 1 root root 706 ... /hpc/local/etc/modulefiles/dev/libnl. The ubuntu2004 leg passed because its newer Modules version tolerates the missing directory. PR #11796 only changes Jenkins status URLs and is unrelated — this is an infra/CI-harness issue, so a rebuild after the modulefiles share is repaired should pass.

Implicated commit: unknown (no UCX commit implicated; [REDACTED:Hex High Entropy String]…/PR #11796 touches only CI status URLs). Nearest relevant code is the retry logic in buildlib/az-helpers.sh (last touched by 5c4ddb1, Yaser Afshar and cfd9cd1, Yossi Itigin — neither introduced this).

File: buildlib/az-helpers.sh:118 (until module avail -t 2>&1 | grep -q "^$module\$"), triggered from buildlib/tools/build_static.sh:17

Suggested fix:

  1. Infra: remove/repair the dangling hpcx-2.51 entry (broken symlink or stale version file) under /hpc/local/etc/modulefiles so Modules 3.x can scan the directory; then re-run /build.
  2. Harden az_module_load so a single bad entry can't break all module loads — e.g. before giving up, check the modulefile directly and load it:
for d in ${MODULEPATH//:/ }; do
    if [ -f "$d/$module" ]; then
        module load "$module" && return 0
    fi
done

and/or filter modulecmd's ERROR: lines out of the module avail -t output so the grep sees the surviving entries.
3. Also make the failure message actionable (it currently only emits an Azure-format warning that is suppressed under Jenkins, RUNNING_IN_AZURE=no, so the stage dies with no explanation).

Security note: the stage log dumps the full environment (env in prepare_build), including a githubData blob containing a base64 basic-auth Artifactory credential. Rotate that Artifactory credential and stop printing githubData/env verbatim (mask it or unset before the dump).

Related: PR #11796 (trigger only, unrelated); no existing issue found for this module-load failure.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id ec7f694f-321d-4ba9-a0ea-4b4ae6a554a2 in the triage console for the audit trail.

@svc-ucx

svc-ucx commented Aug 25, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-gpu-oss · commit 06972371

TL;DR: All four gtest workers hung (not timed out on Jenkins' clock — genuinely stuck) in test_ucp_rma/test_ucp_rma_reg cases that use non-blocking memory registration (UCP_MEM_MAP_NONBLOCK / UCX_REG_NONBLOCK_MEM_TYPES=host, i.e. IB ODP mkeys): the RMA request never completes and the data only partially lands, so gtest aborts after its 900 s connection timeout. The failure is unrelated to PR #11796 (a CI-URL-only change) — investigate the ODP/non-blocking IB registration path (or ODP support in the funk-node image), not the PR.

Full analysis

Summary: Stage Test failed on all 4 parallel workers (nodes funk11/12/19/20) with ucp_test.cc:300 request did not complete on time → test_ucp_memheap.cc:115 data validation failed → test_helpers.cc:57 Connection timed out - abort testing → SIGABRT / make: *** [test] Aborted (core dumped) / exit code 2.

Root cause: UCP RMA put/get requests hang indefinitely when the local buffer is registered non-blocking. Per-worker failing cases from the logs:

  • w0 (funk19): shm_ib_ipc/test_ucp_rma.put_blocking/2 <user_memh> — hangs in the host->host map_nb phase (test_ucp_rma.cc:160 passes UCP_MEM_MAP_NONBLOCK).
  • w1 (funk20): rc/test_ucp_rma_reg.get_nonblocking/1 <nb>
  • w2 (funk12): shm_ib/test_ucp_rma_reg.get_blocking/1 <nb>
  • w3 (funk11): shm_ib_ipc/test_ucp_rma_reg.get_blocking/2 <no_devx> (= NON_BLOCK | NO_DEVX)

All four are NON_BLOCK (test_ucp_rma.cc:672-684 → REG_NONBLOCK_MEM_TYPES=host, which makes the IB MD create on-demand-paging mkeys). Timestamp analysis confirms a hang, not slowness: the log shows exact 180 s silences (e.g. 14:14:46 → 14:17:53 → 14:20:59 → 14:23:51) matching the internal request-wait timeouts, then a 12-minute silence before the abort. Fabric/HCA health is not the cause — in the same runs rc_verbs/uct_p2p_rma_test completed 1 GB put_zcopy/get_zcopy on mlx5_0/1/2, and the non-nb variants of the very same UCP tests (no_rcache, gva, gva_no_rcache, plain) passed on the same nodes. Only ODP-registered transfers stall, and only at the larger random sizes (MB range), which is why it looks variant-random.

Implicated commit: Not the PR head (0697237 / PR #11796 is "CI: Replace Blue Ocean with pipeline-overview URL" — no library code). Most plausible code suspects touching IB memory-key/registration behaviour: a9568621 "UCT/IB: Support relaxed-only memory keys (#11649)" (Roie Danino) and 49b95f02 "UCT/IB: Skip madvise with DONT_FORK if kernel supports RDMA copy-on-fork (#11573)" (Thomas Vegas). Also merged ~2.5 h before this build and touching RMA lane selection: [REDACTED:Hex High Entropy String] "UCP/PROTO: Keep latency singles off lanes beyond the fast-path array (#11808)" (Evgeny Leksikov, src/ucp/rma/put_offload.c:81, src/ucp/rma/amo_offload.c) — less likely, since the hangs are in multi-lane MB-sized put/get, not short/AMO paths.

File: test/gtest/ucp/test_ucp_rma.cc:672-684 (NON_BLOCK variants) and test/gtest/ucp/test_ucp_rma.cc:160 (UCP_MEM_MAP_NONBLOCK phase); hang surfaces at test/gtest/ucp/test_ucp_memheap.cc:106-115 (flush + validate); IB side: src/uct/ib/base/ib_md.c (non-blocking/ODP registration).

Suggested fix:

  1. Do not re-run/merge-block on PR CI: Replace Blue Ocean with pipeline-overview URL #11796 for this — it cannot cause it. Confirm by re-running the same job on plain master.
  2. Reproduce narrowly on one funk node: UCX_REG_NONBLOCK_MEM_TYPES=host ./gtest --gtest_filter='*test_ucp_rma_reg.get_blocking/1*' with UCX_LOG_LEVEL=debug. Check whether ODP is actually functional on the node image (ibv_devinfo -v ODP caps, MLNX_OFED/kernel version, nv_peer_mem/peermem state). Given this is build Initial drop of UCX indentation setup for GNU Emacs #6 of a freshly provisioned GPU fleet, a driver/kernel image without working ODP page-fault handling is the leading explanation — fix the image, or gate ODP off there.
  3. If the node image is fine, bisect the IB registration commits above (a9568621, 49b95f02) with UCX_REG_NONBLOCK_MEM_TYPES=host; a wrong mkey/access-flag choice for ODP MRs produces exactly this signature (silent partial data + never-completing flush).
  4. Do not raise the Jenkins/stage time limit — the process was hung, and the 180 s/900 s test-internal timeouts already fired.

Related: PR #11796 (trigger, CI-only) #11796; PR #11808 #11808 (recent RMA lane-selection change, secondary suspect). No existing issue found for this hang — worth opening one with the four failing test names above.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 2bb5d3bb-09f7-4c88-9fb7-5ed2b48513b3 in the triage console for the audit trail.

@svc-ucx

svc-ucx commented Aug 25, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-coverity-oss · commit 06972371

TL;DR: The Coverity stages fail because module avail on the build agent cannot enumerate /hpc/local/etc/modulefiles (dangling hpcx-2.51 entry aborts the directory scan), so az_module_load tools/cov-2019.12 never finds the module even though the modulefile exists on disk — this is an agent/NFS-automount problem, not a code change from PR #11796.

Full analysis

Summary: Both x86_64/cov/release and x86_64/cov/devel → Coverity stages aborted with Step Coverity failed with exit code=1 after az_module_load tools/cov-2019.12 failed 5 retries.

Root cause: In the Coverity stage log, Environment Modules reports:

ModuleCmd_Avail.c(804):ERROR:64: Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found
ModuleCmd_Avail.c(529):ERROR:57: Error while reading directory '/hpc/local/etc/modulefiles'

modulecmd avail bails out of the entire /hpc/local/etc/modulefiles tree when it hits the stale/missing hpcx-2.51 entry, so module avail -t lists only /usr/share/Modules/modulefiles (dot, module-git, module-info, modules, null, use.own). The very next debug line in the same log proves the Coverity modulefile is present and readable:
-rw-r--r-- 1 root root 285 Feb 25 12:41 /hpc/local/etc/modulefiles/tools/cov-2019.12.

Because az_module_load() decides existence purely by grepping module avail -t output, it declares the module missing, returns 1, and — since coverity.sh runs under bash -eEl — the script dies at the first az_module_load in modules_for_coverity() (the res=$(($res+$?)) accumulation is unreachable dead code). Build #4 on the same branch shows the byte-identical failure at 13:32Z, and the failure happens in <10 s with no timing gaps, confirming an environment issue rather than a hang or a regression from the commit under test (PR #11796 only replaces a Blue Ocean URL with a pipeline-overview URL).

Implicated commit: unknown — not caused by [REDACTED:Hex High Entropy String]; the last functional changes to the module helper are 5c4ddb1a (Yaser Afshar, "BUILD/CI: Add ZE null-driver build and smoke check") and 925746b4 (Alexey Rivkin, CUDA module bump), neither of which introduced this.

File: buildlib/az-helpers.sh:118 (until module avail -t 2>&1 | grep -q "^$module\$"), triggered from buildlib/tools/coverity.sh:49

Suggested fix:

  1. Primary (infra): fix the shared modulefiles tree on the Coverity agent — remove or restore the dangling /hpc/local/etc/modulefiles/hpcx-2.51 entry (broken symlink/stale autofs entry). Once module avail can read the directory, tools/cov-2019.12 will resolve again. Ask the HPC infra owners to re-mount/repair /hpc/local on that node.
  2. Hardening (repo): make az_module_load() not depend on module avail enumeration, which is fragile against one bad subdirectory. For example probe the file directly and let module load be the source of truth:
function az_module_load() {
    module=$1
    retries=5
    until module load "$module" 2>/dev/null; do
        if [ $retries -gt 1 ]; then
            echo "Module $module not loadable, retrying..."
            ls /hpc/local > /dev/null 2>&1   # refresh automount
            sleep 1
        else
            echo "MODULEPATH='${MODULEPATH}'"
            module avail || true
            ls -l /hpc/local/etc/modulefiles/"$module" || true
            azure_log_warning "Module $module cannot be loaded"
            return 1
        fi
        ((retries--))
    done
}
  1. Optional cleanup: modules_for_coverity() in buildlib/tools/coverity.sh:47-62 accumulates $? but runs under set -e, so it aborts on the first failure and never reports the full list of missing modules — wrap each call as az_module_load X || res=$((res+1)) to get useful diagnostics in one run.

Related: PR #11796 (the triggering PR — unrelated to the failure); same failure reproduced in UCX-OSS/ucx-coverity-oss build #4.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 05dbc8ae-2edb-449b-85c0-e1033cc0575a in the triage console for the audit trail.

@svc-nvidia-pr-review

Copy link
Copy Markdown

🤖 Starting review — findings will be posted here when done.

Comment thread buildlib/tools/coverity.sh Resolved
@svc-ucx

svc-ucx commented Aug 25, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX PR (Codestyle commit title) · commit 08e1ede4

TL;DR: The "commit title" codestyle job failed because PR #11796 contains a commit titled debug CI failure, which does not match the required MODULE: Description format; drop or rename/squash that commit (e.g. CI: Debug CI failure) and force-push.

Full analysis

Summary: Azure Pipelines job UCX PR (Codestyle commit title) build 132545 failed at the codestyle_check_commit_title bash step with Bad commit title: 'debug CI failure' and Bash exited with code '1'.

Root cause: This is a genuine lint failure, not infrastructure flakiness. codestyle_check_commit_title() iterates the PR's non-merge commits and requires each subject line to match the regex ^[0-9A-Z/_-]+:\ [[:alnum:]_] — i.e. an uppercase module prefix followed by : and then an alphanumeric character. PR #11796 (branch HPCINFRA-4739, head 08e1ede) has two commits:

  • CI: Replace Blue Ocean with pipeline-overview URL → reported "Good commit title"
  • debug CI failure → reported "Bad commit title" (lowercase, no MODULE: prefix)

The step ran only ~30 ms with no gaps, so there is no timeout/hang aspect. Secondary defect: the step script uses set -eE, so the non-zero return from codestyle_check_commit_title aborts the script immediately and the intended friendly ##vso[task.logissue] message pointing at the contributor guidelines is never printed — the log shows only a bare Bash exited with code '1', which makes the failure harder to self-diagnose.

Implicated commit: [REDACTED:Hex High Entropy String] (PR #11796 head, the commit titled debug CI failure); the checker itself is unchanged behavior from cfd9cd1 "BUILD/CI: Limit PR commit range checks (#11527)" by Yossi Itigin.

File: buildlib/tools/codestyle.sh:14 (regex) — triggered via buildlib/pr/codestyle.yml:17-30

Suggested fix:

  1. Primary (PR author action): remove the temporary debug CI failure commit, or squash/reword it into the properly-prefixed commit. E.g. git rebase -i origin/master, then either drop it or reword to CI: Debug CI failure, then force-push. There is nothing to fix in UCX itself.
  2. Optional CI hardening in buildlib/pr/codestyle.yml: set -eE defeats the if [[ $? -ne 0 ]] branch below it. Change the invocation so the error message is actually emitted, e.g.:
    set -eE
    source ./buildlib/tools/codestyle.sh
    base_revision=$(git rev-parse "$(Build.SourceVersion)^1")
    head_revision=$(git rev-parse "$(Build.SourceVersion)^2")
    if ! codestyle_check_commit_title "$base_revision..$head_revision"; then
        url="https://github.com/openucx/ucx/wiki/Guidance-for-contributors#general-guidelines"
        echo "##vso[task.logissue type=error]Bad commit title(s), see $url for more info."
        echo "##vso[task.complete result=Failed;]"
    fi
    This keeps the failure but surfaces the guidance link to contributors.

Related: PR #11796; checker introduced/last modified by #11527; style rules at https://github.com/openucx/ucx/wiki/Guidance-for-contributors#general-guidelines

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id bb330e65-cdcd-4c2d-831a-b6595390ccf8 in the triage console for the audit trail.

@ntsemah

ntsemah commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

/build

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-codestyle-oss · commit 08e1ede4

TL;DR: The Commit Title codestyle stage failed because commit 08e1ede4 is titled debug CI failure, which doesn't match UCX's required MODULE: Description title format; rename/amend the commit title (e.g. CI: Debug CI failure) and force-push.

Full analysis

Summary: Stage Commit Title (node 53) of UCX-OSS/ucx-codestyle-oss #5 failed with exit code 1 — Bad commit title: 'debug CI failure'.

Root cause: codestyle_check_commit_title() iterates over the PR's non-merge commits and requires each subject line to match the regex ^[0-9A-Z/_-]+:\ [[:alnum:]_], i.e. an uppercase module prefix followed by ": " and an alphanumeric word. The branch HPCINFRA-4739 contains commit [REDACTED:Hex High Entropy String] with the subject debug CI failure — all lowercase and with no MODULE: prefix — so the regex does not match and the check sets err=1, aborting the parallel stage before Format Check, Authors Check, Codespell and Ctags could run (hence their ? status). The second commit in the range, CI: Replace Blue Ocean with pipeline-overview URL, passed, confirming the checker itself is working correctly. This is a genuine contributor-side violation, not a CI infrastructure problem.

Implicated commit: [REDACTED:Hex High Entropy String] — Noam Tsemah, "debug CI failure" (2026-08-25)

File: buildlib/tools/codestyle.sh:14 (title regex in codestyle_check_commit_title)

Suggested fix: Rewrite the offending commit's title so it satisfies the convention, then force-push the branch:

git rebase -i <base>        # or: git commit --amend on that commit
# retitle 08e1ede4 -> "CI: Debug CI failure"  (or a descriptive title such as
#                     "CI: Fix pipeline-overview URL in codestyle job")
git push --force-with-lease origin HPCINFRA-4739

Since the commit is described as a throwaway debug change, the cleaner option is to drop it entirely or squash it into the adjacent CI: Replace Blue Ocean with pipeline-overview URL commit, which already has a valid title. No change to buildlib/tools/codestyle.sh is warranted — the check behaved as designed. Note that because all five checks run as one parallel group that aborts on first failure, the remaining codestyle checks are still unverified; re-run the job after retitling.

Related: PR #11796 (this PR); prior commit-title-check failures: #11218, #11480, #8246. Range-limiting logic last touched by cfd9cd1f "BUILD/CI: Limit PR commit range checks (#11527)".

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id f7ca76f3-258a-4242-8783-5867f7e6d00c in the triage console for the audit trail.

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-build-static-oss · commit 08e1ede4

TL;DR: The centos7-ib static build failed because module avail on the shared /hpc/local/etc/modulefiles tree aborts (dangling hpcx-2.51 directory), so az_module_load dev/libnl never sees the module and returns 1 — an infra/module-tree problem, not a code regression from PR #11796. Fix the stale hpcx-2.51 entry on the /hpc/local share and harden az_module_load to not depend on a full module avail listing.

Full analysis

Summary: Stage Build Static (x86_64/centos7-ib, node dl325g11-3516) failed after ~17s with exit code 1 at az_module_load dev/libnl, before configure/make ever ran.

Root cause: Evidence from the stage log (node 62 / 37):

+ module avail -t
+ grep -q '^dev/libnl$'
Module dev/libnl not found, retrying...   (x4, then give up)
+ module avail
ModuleCmd_Avail.c(804):ERROR:64: Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found
ModuleCmd_Avail.c(529):ERROR:57: Error while reading directory '/hpc/local/etc/modulefiles'
------------------------ /usr/share/Modules/modulefiles ------------------------
+ ls -l /hpc/local/etc/modulefiles/dev/libnl
-rw-r--r-- 1 root root 706 Feb 25 12:41 /hpc/local/etc/modulefiles/dev/libnl

The modulefile itself exists and is readable (ls -l succeeds), but Environment Modules 3.x aborts enumeration of the entire /hpc/local/etc/modulefiles directory when it hits the dangling hpcx-2.51 entry (stale symlink / removed dir on the autofs-mounted /hpc share). Consequently module avail -t lists only /usr/share/Modules/modulefiles and dev/libnl never matches. az_module_load uses that listing as a pre-flight existence check, exhausts its 5 retries, and returns 1; build_static.sh runs under #!/bin/bash -eExl, so the non-zero return kills the stage immediately.

This is environment-specific, not the PR: the parallel x86_64/ubuntu2004-mofed5.0 Build Static stage (node 100) succeeded on the same commit, and PR #11796 only changes GitHub commit-status URLs.

Implicated commit: unknown — no UCX commit implicated. The module avail-based existence check in az_module_load predates the recent buildlib/az-helpers.sh changes (latest: 5c4ddb1a, Yaser Afshar; cfd9cd1f, Yossi Itigin); the trigger is the broken hpcx-2.51 entry in the shared /hpc/local/etc/modulefiles tree.

File: buildlib/az-helpers.sh:118 (until module avail -t 2>&1 | grep -q "^$module\$"), invoked from buildlib/tools/build_static.sh:17

Suggested fix:

  1. Infra (real fix): repair the module tree on the /hpc/local share — remove or restore the dangling /hpc/local/etc/modulefiles/hpcx-2.51 directory/symlink. Any job doing module avail on that path will keep failing until then.
  2. Code hardening so one bad modulefile directory can't break unrelated module loads — check the modulefile path directly and/or just try the load:
function az_module_load() {
    local module=$1 retries=5
    until [ -e "/hpc/local/etc/modulefiles/${module}" ] || \
          module avail -t 2>/dev/null | grep -q "^${module}\$"; do
        ...retry/automount refresh...
    done
    module load "$module" || { azure_log_warning "Module $module cannot be loaded"; return 1; }
}
  1. Unrelated but urgent: prepare_build runs env, which dumps the githubData variable into the build log — it contains an Artifactory basic-auth credential in base64. Rotate that Artifactory credential and stop echoing the full environment (or mask githubData/artifactory_token) in buildlib/tools/common.sh's prepare_build.

Related: #11796 (PR under test; unrelated to this failure)

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-coverity-oss · commit 08e1ede4

TL;DR: Both Coverity stages failed because module load tools/cov-2019.12 never succeeds — Environment Modules aborts scanning /hpc/local/etc/modulefiles after hitting a missing hpcx-2.51 directory, so the module is never listed; the debug ERR trap added in HEAD commit 08e1ede then sleep 1800ed and tripped the 30‑minute stage timeout. Fix the broken hpcx-2.51 entry on the CI /hpc share (and remove/shorten the 1800s debug sleep so the job fails fast).

Full analysis

Summary: x86_64/cov/release and x86_64/cov/devel → Coverity stages (node IDs 62, 80) aborted with FlowInterruptedException: Timeout has been exceeded after az_module_load tools/cov-2019.12 failed.

Root cause: Environment-infrastructure failure, not a code bug in UCX:

  • az_module_load decides a module exists by module avail -t | grep -q "^$module$".
  • In this build modulecmd bailed out while enumerating the module tree:
    ModuleCmd_Avail.c(804):ERROR:64: Directory '/hpc/local/etc/modulefiles/hpcx-2.51' not found
    followed by ModuleCmd_Avail.c(529):ERROR:57: Error while reading directory '/hpc/local/etc/modulefiles'.
    Because the whole /hpc/local/etc/modulefiles scan errors out, only /usr/share/Modules/modulefiles (dot, module-git, modules, null, use.own) is listed, so tools/cov-2019.12 is never matched — even though the diagnostic ls -l /hpc/local/etc/modulefiles/tools/cov-2019.12 in the same log proves the modulefile is present and readable. All 5 automount retries therefore fail deterministically; the ls /hpc/local retry workaround cannot help since the problem is a missing/dangling hpcx-2.51 entry, not a cold automount.
  • The 30-minute stage duration is a symptom: after modules_for_coverity returned 1, the ERR trap installed at buildlib/tools/coverity.sh:130 printed DEBUG: pod=... sleeping 1800s for kubectl exec and slept. The log shows a single ~30-minute gap (06:39:38 → 07:09:31) containing nothing but that sleep 1800, ended by Jenkins Sending interrupt signal to process. The real failure took 6 seconds; the timeout is purely the debug sleep. Raising the stage timeout would be the wrong fix.

Implicated commit: [REDACTED:Hex High Entropy String] — Noam Tsemah, "debug CI failure" (adds the ERR trap + 1800s sleep and the az_module_load retry/diagnostic block). This commit did not cause the module-load failure but converted a fast, clearly-reported failure into an opaque 30-minute timeout.

File: buildlib/tools/coverity.sh:130 (debug ERR trap / sleep 1800); buildlib/az-helpers.sh:114-136 (az_module_load detection via module avail -t); broken external path /hpc/local/etc/modulefiles/hpcx-2.51

Suggested fix:

  1. Infra (real fix): restore or delete the hpcx-2.51 entry under /hpc/local/etc/modulefiles on the shared /hpc NFS/autofs export so modulecmd can enumerate the tree again. Ask the CI/infra owners to verify with module avail -t on a ucx-coverity-cov pod — it must list tools/cov-2019.12 without ERROR:64.
  2. Make az_module_load robust to a partially-unreadable module tree: instead of relying solely on module avail -t, fall back to a direct existence check plus a real load attempt, e.g.
    if [ -f "/hpc/local/etc/modulefiles/$module" ] && module load "$module"; then return 0; fi
    and treat ERROR:57 Error while reading directory from module avail as a retryable/hard error with an explicit message rather than "module not found".
  3. Remove the debug ERR trap in buildlib/tools/coverity.sh:130 before merging PR CI: Replace Blue Ocean with pipeline-overview URL #11796, or default DEBUG_MODULE_FAIL_SLEEP to 0 and gate it behind an explicit opt-in env var so a module failure fails the stage in seconds with the diagnostic output already printed.

Related: PR #11796 (CI: Replace Blue Ocean with pipeline-overview URL, branch HPCINFRA-4739) — carries the debug commit 08e1ede; no existing issue found for the hpcx-2.51 modulefiles breakage.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id c6a9ed81-a44d-40d6-b5d9-2bfda5d5161b in the triage console for the audit trail.

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-dl-gpu-oss · commit 08e1ede4

TL;DR: The Checkout & test stage was aborted after ~62 min because ./examples/ucp_client_server -m host -c stream -s 1 (client, port 10510) hung — the log shows a 52-minute dead gap (06:53:44 → 07:46:09) with zero output before a human killed the job; this is a hang in the UCP stream/wireup path on the aarch64 DL node, not something PR #11796 (a CI-URL-only change) can cause.

Full analysis

Summary: Stage 160 "Checkout & test" (aarch64/build_helper_dl) hung in the UCP client-server example loop and was manually aborted; the abort/Terminated messages are symptoms, not the cause.

Root cause: Log timestamps show continuous progress through all am and tag msg-size iterations (each ~15 s apart, driven by the sleep 15 in run_client_server_app). The last meaningful lines are:

[06:53:29.470] taskset -c 0 ./examples/ucp_client_server -m host -c stream -s 1 -p 10510
[06:53:29.470] server is listening on IP 0.0.0.0 port 10510
[06:53:44.328] client_pid=1535645 ; wait 1535645
[06:53:44.328] taskset -c 1 ./examples/ucp_client_server -m host -c stream -s 1 -a 127.0.0.1 -p 10510
[07:46:09.544] Sending interrupt signal to process        <-- 52 min of silence

The client never printed even Client: iteration #1, so it never completed its first ucp_stream_send_nbx. It was stuck either in sockaddr connection establishment/wireup (ucp_ep_create on 127.0.0.1) or spinning in request_wait()'s unbounded while (ctx->complete == 0) ucp_worker_progress(...) loop (examples/ucp_client_server.c:335-337). run_client_server_app uses a bare wait ${client_pid} (contrib/test_jenkins.sh:201) with no timeout, so a hung client blocks the stage until wall-clock death.

This is the first stream-API iteration; am and tag for all message sizes passed. PR #11796 only changes a Jenkins URL (Blue Ocean → pipeline-overview) and touches no UCX source, so it cannot be the trigger — this is a flaky/environmental hang on this aarch64 GPU node (or a latent stream-wireup bug), not a regression from the commit under test.

Implicated commit: none — PR #11796 / [REDACTED:Hex High Entropy String] is a CI-URL-only change and is not implicated. No recent commits to examples/ucp_client_server.c (latest: 1af57d6, rakhmets, 2024-11-29).

File: contrib/test_jenkins.sh:201 (unbounded wait ${client_pid}); hang site examples/ucp_client_server.c:335-337 (request_wait busy loop), reached from send_recv_stream at examples/ucp_client_server.c:402-433

Suggested fix:

  1. Re-run the build — do not raise the stage time limit; the log has a 52-minute zero-output gap, which is a hang, not slowness.
  2. Make the hang self-diagnosing instead of eating the whole stage: wrap the client/server launches in run_client_server_app with timeout (e.g. timeout -s ABRT 120 taskset -c ... &) so a stuck iteration fails fast, and on timeout dump gdb -p $client_pid -batch -ex "thread apply all bt" plus ucx_info -d/-e output.
  3. If it reproduces on the same node, re-run that single case with UCX_LOG_LEVEL=debug UCX_PROTO_INFO=y and record the selected transports for the 127.0.0.1 sockaddr endpoint — the am/tag cases passed, so suspect stream-specific wireup/first-send on the loopback TCP path rather than the example itself.
  4. Meanwhile, unblock PR CI: Replace Blue Ocean with pipeline-overview URL #11796 by re-triggering; its diff cannot affect this test.

Related: PR #11796 (the PR under test — CI URL change only). No existing issue found for a ucp_client_server stream-API hang; worth opening one with the timestamps above if it recurs.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 5217f95c-1ce7-483e-8e90-d68693f9545d in the triage console for the audit trail.

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-gpu-oss · commit 08e1ede4

TL;DR: All four gtest shards failed on four different nodes (funk06/11/12/27) because UCP connection establishment over the nodes' own IB/IPoIB addresses (1.1.90.x / 1.1.91.x) returns "Destination is unreachable" — a broken fabric/IPoIB state on the allocated GPU test nodes, not a code change. Fix the node fabric (or drain those nodes) and add a fail-fast IB/IPoIB health check plus a timeout wrapper around run_ucx_perftest_with_daemon, which hung for ~57 minutes.

Full analysis

Summary: Test stages 253/268/289/292 of UCX-OSS/ucx-test-gpu-oss #7 all failed: sockaddr/CM gtests timed out or aborted, and one shard hung in run_ucx_perftest_with_daemon until the build was manually aborted.

Root cause: Environmental — RDMA connectivity on the allocated nodes is broken while the IB ports themselves enumerate as active. Evidence:

  • UCT loopback tests over ud_mlx5/mlx5_0..2 pass, and ucx_info shows all three mlx5 devices with active resources, so the local devices are fine.
  • Every UCP sockaddr/CM test that connects to the node's own IPoIB address fails: server listening on 1.1.90.6:... → ignoring error Destination is unreachable on endpoint ... → [ SKIP ] (cannot connect to server), each burning the full ~270 s wireup timeout (udx/test_ucp_sockaddr_with_wakeup = 1,354,198 ms total for 15 tests; all/test_ucp_sockaddr_cm_private_data = 545,867 ms).
  • Where the test does not skip, it fails hard: test/gtest/ucp/test_ucp_sockaddr.cc:2280 send_buf == recv_buf false, test_ucp_sockaddr.cc:2421 server endpoint is not created, test_ucp_sockaddr.cc:2569 arg.received false, plus an mpool leak warning (mpool.c:40 ... was not returned to mpool ucp_requests) caused by the never-completing request.
  • The accumulated stalls trip the gtest watchdog: test/gtest/common/test_helpers.cc:57: Connection timed out - abort testing → Caught signal 6 (Aborted) inside ucp_request_pending_add / ucp_am_send_nbx (shards w2 and w3, exit code 2).
  • Shard w1 (stage 289) is a pure hang, not slowness: last output is taskset -c 1 /hpcx/install/bin/ucx_perftest ... -g 1.1.91.27:10501 -G 1.1.91.27:10500 funk27 -p 10502 at 06:49:32, then zero output for 57 minutes until 07:46:04 Sending interrupt signal. The perftest daemon client never connected — same unreachable-fabric symptom — and nothing bounds that step, so it consumed the whole build window.

The PR under test cannot explain this: PR #11796 is "CI: Replace Blue Ocean with pipeline-overview URL" and the only branch commit, 08e1ede ("debug CI failure", Noam Tsemah), touches buildlib only. No UCX transport/reachability code changed recently (last relevant commits to src/uct/ib/base/ib_iface.c are from early August and unrelated).

Implicated commit: none — not a source regression. Branch commit 08e1ede (Noam Tsemah, "debug CI failure", buildlib) is CI-only and unrelated to the failures.

File: test/gtest/ucp/test_ucp_sockaddr.cc:2280 (and :2421, :2569) — failure sites; test/gtest/common/test_helpers.cc:57 — watchdog abort; contrib/test_jenkins.sh (run_ucx_perftest_with_daemon) — unbounded hang site

Suggested fix:

  1. Fix the fabric on the funk GPU pool before re-running: verify a subnet manager is present and LIDs are assigned (ibstat, sminfo), that IPoIB interfaces ibs2/ibs7f0 are UP with the 1.1.90.x/1.1.91.x addresses, and that the node can reach its own IPoIB address (ping 1.1.91.<n>, ucx_perftest loopback over ud_x). Drain/exclude nodes that fail this.
  2. Add a fail-fast pre-flight health check in the Test stage (e.g. ibv_devinfo port state + ping -c1 on each ibdev2netdev IPoIB address + a short ucx_perftest self-loopback). Failing in 30 s beats burning 3.5 h of four executors.
  3. Wrap run_ucx_perftest_with_daemon and its daemon/client invocations in timeout <N> (and kill the daemons on exit) in contrib/test_jenkins.sh, so an unreachable peer produces a diagnosable failure instead of a 57-minute silent hang. Do not raise the pipeline time limit — this was a hang, not slow progress.
  4. Consider lowering the gtest sockaddr connect timeout in CI so an unreachable fabric yields fast skips rather than 270 s per test.

Related: PR #11796 (the triggering PR — CI URL change only, unrelated to the failure); branch commit 08e1ede indicates the CI owner was already debugging this environment.

@svc-nvidia-pr-review

Copy link
Copy Markdown

🤖 Starting review — findings will be posted here when done.

@ntsemah

ntsemah commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

/build

Comment thread buildlib/tools/coverity.sh Resolved
@svc-nvidia-pr-review

Copy link
Copy Markdown

Test/validation coverage note: Per REVIEW.md, build/CI changes should show the intended CI behavior changed. The URL change is low-risk and self-evident, but there's no dry-run/CI output demonstrating that the pipeline-overview link resolves correctly. Worth confirming the link works before merge, though it does not block.

@svc-nvidia-pr-review

Copy link
Copy Markdown

🤖 Starting review — findings will be posted here when done.

@ntsemah

ntsemah commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

/build

@svc-nvidia-pr-review

Copy link
Copy Markdown

🤖 Review complete — no issues found.

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-dl-gpu-oss · commit f0fcdd62

TL;DR: The build failed in the Slurm Allocate stage — salloc sat queued in partition gb300nvl72_ci for the full --immediate=3600 window and gave up with "Unable to allocate resources: Connection timed out". This is a cluster-capacity/infrastructure failure, not a defect in PR #11796; re-run the job (and ideally make the allocation step retry/report as infra-failure instead of hard-failing).

Full analysis

Summary: Stage Allocate (node 140) of aarch64/build_helper_dl failed after 1 hour: salloc: error: Unable to allocate resources: Connection timed out for pending job 1953546.

Root cause: The pipeline requested an exclusive 1-node allocation on the GB300 CI partition:
salloc -N 1 -p gb300nvl72_ci --job-name=ucx-ci-dl-8 --immediate=3600 --time=02:45:00 --no-shell --account=blackwell-ci (invoked 12:36:11Z). Slurm accepted it as pending job 1953546 ("queued and waiting for resources") and never got a free node within the --immediate=3600 (1 h) budget, so it aborted at 13:36:20Z with exit code 1, which propagated as parallel task failed with msg: hudson.AbortException: script returned exit code 1.

The ~60-minute log gap (12:36:11 → 13:36:20) is exactly the --immediate deadline, i.e. Slurm queue wait — not a hung UCX process. No UCX source was compiled or tested; nothing in this build reached the test phase. The pipeline_stop stage confirms this ("WARNING: No job ID files found in /mnt/pvc/ucx-test-dl-gpu-oss/" — no allocation was ever recorded).

Secondary infra noise, non-fatal: the build_helper_dl agent pod was initially rejected three times with exceeded quota: resourcequota-nbu-swx-ucx, requested: cpu=4500m, used: cpu=399, limited: cpu=400 before succeeding on retry at 12:35:44Z. The namespace CPU quota is essentially saturated (399/400), so this job is also at risk of agent-provisioning flakiness.

Implicated commit: none — commit f0fcdd6 / PR #11796 ("CI: Replace Blue Ocean with pipeline-overview URL") only changes a CI URL and cannot affect Slurm allocation. Pipeline library used was swx-jenkins-lib@8a2b2c6d ("slurm: verify scctl installer checksum before executing it"), also unrelated to allocation logic.

File: not in this repo — the failing step is the Allocate stage calling slurm.allocation from Mellanox-lab/swx-jenkins-lib@8a2b2c6d; the failing command is logged at job/UCX-OSS/job/ucx-test-dl-gpu-oss/8 stage node 140.

Suggested fix:

  1. Immediate: re-trigger ucx-test-dl-gpu-oss for PR CI: Replace Blue Ocean with pipeline-overview URL #11796 — the failure is environmental. Check sinfo -p gb300nvl72_ci / squeue -p gb300nvl72_ci for drained or fully-booked nodes and for stale ucx-ci-dl-* allocations left behind by earlier builds that were not cleaned up.
  2. Pipeline hardening: wrap the slurm.allocation step in a retry(N) and/or distinguish "no resources available" from a real test failure — report it as UNSTABLE/aborted-infra rather than FAILURE, so PR authors aren't blamed for cluster contention. Do not simply raise immediateTimeout beyond 3600 s; it would only make each blocked build burn more wall clock while holding a k8s agent pod.
  3. Quota: the nbu-swx-ucx namespace is at 399/400 CPU while this pod requests 4500 m. Either raise the ResourceQuota or reduce the build_helper_dl container request (currently cpu: 4000m, plus jnlp overhead) so agent creation doesn't need three retries.

Related: #11796 (the PR under test; unrelated to the failure)

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-gpu-oss · commit f0fcdd62

TL;DR: The x86_64/build_helper_ucx/w0 "Test" stage died with a Kubernetes exec-stream i/o timeout in the middle of compiling gtest objects — an infrastructure/agent-connectivity failure, not a UCX code defect; retry the build and harden the pipeline step against stream drops.

Full analysis

Summary: Build #8 failed only in parallel branch w0 (stage id 259, "Test"); the containerized step was terminated by Error: error streaming command in container: error reading from error stream: next reader: read tcp ...:33822->...:443: i/o timeout, reported as Step Test failed with exit code=1.

Root cause: Infrastructure, not code. The log shows a completely healthy build: libucp.so linked cleanly, ucx_info, ucx_perftest, io_demo, libgtest.a all built, and gtest sources were compiling steadily with output every 1–3 seconds right up to 14:28:27.476Z (-c -o ucp/gtest-test_ucp_tag_probe.o ... ucp/test_ucp_tag_probe.cc). There is no compiler error, no -Werror diagnostic, and no test output at all — the next and final line is at 14:29:35.184Z, a ~68 s gap, and it is the Jenkins Kubernetes plugin losing its exec stream to the cluster API endpoint on port 443. That is a broken control-plane/websocket connection to the pod, which the pipeline surfaces as a generic exit code=1.

Corroborating evidence that this is environmental:

  • The identical commit f0fcdd6 built and tested successfully in the three sibling branches w1 (4,800 s), w2 (6,387 s), w3 (5,281 s). Only w0 failed.
  • w0's runtime (6,948 s) is in the same range as the passing w2 (6,387 s), so this is not a wall-clock/timeout kill and not a hang — the 68 s silence is just the TCP read timeout window before the plugin gave up.
  • No artifacts were produced for the build, consistent with the step being severed rather than failing a test assertion.

Implicated commit: none — the PR commit is not at fault (same commit passed on 3 of 4 parallel workers). No UCX source file is implicated.

File: unknown (no source file implicated; failure originates in the Jenkins Kubernetes agent transport, surfaced at stage node 259 of UCX-OSS/ucx-test-gpu-oss #8)

Suggested fix:

  1. Re-run the failed build — this is a transient, retryable infrastructure error. Do not chase a code fix and do not raise any time limit (activity was continuous up to the drop).
  2. Harden the pipeline so a lost exec stream doesn't fail the PR:
    • Wrap the per-worker Test step in retry(2) { ... } in the Jenkinsfile so a stream drop re-runs instead of failing the branch.
    • Raise the Kubernetes plugin's connection/idle timeouts (Read Timeout / Connection Timeout in the cloud config, or KUBERNETES_CONNECTION_TIMEOUT / KUBERNETES_READ_TIMEOUT), and consider enabling websocket-based containerStep connections which are more resilient than SPDY exec.
    • Redirect build/test output to a file inside the container and archive it as an artifact, so a broken stream doesn't destroy diagnosability (note: this build produced zero artifacts, which is why the root cause had to be inferred from the console tail).
  3. Ask infra to check the agent node that hosted w0 around 2026-08-26T14:28–14:29Z for kubelet/API-server connectivity blips or node pressure; if these i/o timeout aborts recur across builds, it's a cluster networking issue rather than a one-off.

Related: none found — a repository search for error streaming command in container i/o timeout returned no matching issues or PRs. Build under investigation: UCX-OSS/ucx-test-gpu-oss #8 (branch HPCINFRA-4739, PR #11796).

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-gpu-oss · commit f0fcdd62

TL;DR: This build did not fail on a code or test defect — it was manually aborted mid-run ("Aborted by Noam Tsemah") while the gtest suite was passing, and the resulting SIGTERM cascade killed the pipeline_stop cleanup stage, producing the ABORTED/hudson.AbortException result. No fix is needed in UCX; just re-run the build (and note that the interrupted cleanup leaked SLURM allocations).

Full analysis

Summary: UCX-OSS/ucx-test-gpu-oss #9 finished as ABORTED after a human abort interrupted the running gtest worker x86_64/build_helper_ucx/w2 and then the pipeline_stop cleanup stage.

Root cause: Manual cancellation, not a test or build error.

  • Right up to the abort the log shows continuous, healthy activity: shm_ib/test_ucp_sockaddr_destroy_ep_on_err.* cases each finishing [ OK ] in ~600 ms, with timestamps advancing every ~0.6 s from 14:39:54 to 14:40:08. The largest inter-line gap is well under a second, so this was not a hang and not a wall-clock timeout.
  • At 14:40:08.170Z, immediately after [ RUN ] ...onesided_c2s_sforce/11, the log reads Aborted by Noam Tsemah → Sending interrupt signal to process / Killing processes → Terminated. The subsequent Failed in branch x86_64/build_helper_ucx/w2 is the SIGTERM being reported as a branch failure, i.e. a symptom of the abort.
  • The abort then propagated into the cleanup stage: pipeline_stop was iterating the 4 SLURM job-ID files and was terminated in the middle of the third one (job_id_w2_9.txt, SLURM job 85215), right after scctl --raw-errors login — Terminating sh (pipeline_stop). The agent pod went away (seems to be removed or offline), yielding hudson.AbortException: pipeline_stop failed ... FlowInterruptedException, Hard kill!, Finished: ABORTED.
  • The commit under test, f0fcdd62 "CI: Replace Blue Ocean with pipeline-overview URL" (same author who aborted the build), is a cosmetic CI URL change and is unrelated to the gtest output in the log.

Secondary, real robustness bug exposed: because pipeline_stop loops sequentially over /mnt/pvc/job_id_*_${BUILD_NUMBER}.txt and calls stop_slurm_allocation.sh (which runs set -xe and does a fresh scctl upgrade/login per job), an interrupt part-way through leaks the remaining allocations — SLURM jobs 85215 (w2) and the 4th worker's job were never scanceled, and their job_id_*.txt files were left on the PVC.

Implicated commit: none for the failure itself. Build tested f0fcdd62 (Noam Tsemah, "CI: Replace Blue Ocean with pipeline-overview URL"), which is not the cause. The leaked-cleanup weakness dates to ffc2138f (Iaroslav Sydoruk, "CI: Add GPU SLURM test pipeline for scctl cluster").

File: .ci/scripts/stop_slurm_allocation.sh:4 (set -xe) and the pipeline_stop loop that invokes it once per /mnt/pvc/job_id_*_${BUILD_NUMBER}.txt

Suggested fix:

  1. No UCX code change is required for this failure — simply re-trigger ucx-test-gpu-oss for PR CI: Replace Blue Ocean with pipeline-overview URL #11796 / commit f0fcdd62. Do not treat this as a flaky test or raise any timeout.
  2. Manually reclaim the leaked resources: scancel 85215 plus the w3 job id, and delete any stale /mnt/pvc/job_id_*_9.txt files.
  3. Harden cleanup so an abort can't leak allocations: run the pipeline_stop cleanup inside a catchError/post { always { ... } } block wrapped in timeout(...) so Jenkins lets it complete on abort, iterate all job files with a per-file || true (don't let one failure or interrupt abandon the rest), and log in to scctl once before the loop instead of per job to shrink the interruptible window.

Related: #11796 (the PR being built; CI-URL-only change, unrelated to the abort)

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-dl-gpu-oss · commit f0fcdd62

TL;DR: The build wasn't a code failure — the ucp_client_server -m host -c stream -s 1 client process hung and produced no output for 2h09m until Jenkins killed the job; the PR (#11796) only touches CI URL strings, so this is an environment/product hang in the UCP stream example, aggravated by run_client_server_app having no per-test timeout.

Full analysis

Summary: Stage Checkout & test (node 160) was ABORTED by the Jenkins job timeout while ./examples/ucp_client_server -m host -c stream -s 1 -a 127.0.0.1 -p 10510 was blocked in wait ${client_pid}.

Root cause: The log shows continuous, fast progress through all am and tag message sizes (each iteration ~16s, dominated by the fixed sleep 15), then a single enormous silence gap:

  • 13:31:46.584 — last application output: + taskset -c 1 ./examples/ucp_client_server -m host -c stream -s 1 -a 127.0.0.1 -p 10510
  • 15:41:12.755 — Sending interrupt signal to process / Timeout has been exceeded

That is a ~2 hour 9 minute gap with zero output — the very first stream-API case never printed Client: iteration #1, i.e. the client hung during connect / ucp_stream_recv+progress against the still-running server. This is a hang, not slowness, so raising the job time limit is not the fix.

The failure is unrelated to the commit under test: PR #11796 is "CI: Replace Blue Ocean with pipeline-overview URL", a Jenkins-URL-only change with no effect on UCX runtime or on the stream code path. Contributing CI weakness: run_client_server_app() in contrib/test_jenkins.sh runs wait ${client_pid} with no timeout, so one hung example consumes the entire job budget and the server is never killed to force a client error — which is why a single hang produced a bare "Timeout has been exceeded" with no diagnostics.

Implicated commit: unknown — not caused by f0fcdd6 (PR #11796, CI URL change only). No recent commits to examples/ucp_client_server.c (last: 1af57d6, 2024-11-29, rakhmets).

File: contrib/test_jenkins.sh:201 (wait ${client_pid} — unbounded) ; hung binary: examples/ucp_client_server.c (STREAM path, -c stream -s 1)

Suggested fix:

  1. Re-run the build — this is very likely a flaky/environment hang on the aarch64 dl-gpu node and should not block the CI-only PR.
  2. Make the hang self-diagnosing and bounded, in run_client_server_app():
    • wrap both processes with a timeout, e.g. timeout -s ABRT 120 taskset -c $affinity_client ... (and similarly for the server), so a hang aborts in ~2 min with a core/backtrace instead of eating 2+ hours;
    • on client timeout, dump state before killing the server (gstack/gdb -p ${client_pid} -batch -ex "thread apply all bt") and set UCX_LOG_LEVEL=info for the examples so the transport selection for the stream case is captured.
  3. To root-cause the hang itself, reproduce with UCX_LOG_LEVEL=debug ./examples/ucp_client_server -m host -c stream -s 1 on the same aarch64 dl-gpu image; the fact that am and tag at all sizes passed and only STREAM hung points at the stream send/recv completion path or the transport chosen for it on that node, not at generic connection establishment.

Related: #11796 (the PR under test — CI URL change, not the cause)

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-gpu-oss · commit f0fcdd62

TL;DR: All four GPU test workers died because test_ucp_rma.get_nonblocking hung — large multi-lane RMA GET requests never completed (two independent 3-minute stalls on two different nodes/transports), tripping gtest's "Connection timed out - abort testing" watchdog; this is a master-side RMA/lane-selection regression, not caused by PR #11796 (which only edits CI URLs).

Full analysis

Summary: x86_64/build_helper_ucx/w0..w3 "Test" stages failed: dcx/test_ucp_rma.get_nonblocking/0 (funk23) and shm_ib_ipc/test_ucp_rma.get_nonblocking/0 (funk05) hung on the largest message sizes, then gtest aborted with SIGABRT (make: *** [Makefile:4714: test] Aborted (core dumped), exit code 2).

Root cause: A hang in the UCP RMA GET completion path, not a slow test. Timestamp gaps prove it:

  • w0: last progress line host->host 100x128 ... 4x24455177 at 15:05:59, then 3m07s of silence → ucp_test.cc:300 UCX ERROR request 0x555558623798 did not complete on time, then test_ucp_memheap.cc:115: data validation failed; a second stall 15:09:06 → 15:12:12, then at 15:24:04 the global watchdog fired: test_helpers.cc:57 Connection timed out - abort testing → Caught signal 6.
  • w2: identical signature — 15:27:04 → 15:30:10 stall, same did not complete on time + test_ucp_memheap.cc:115 failure, second stall 15:30:10 → 15:33:17.

Both failures are the last, largest size step of get_nonblocking (multi-lane BW path, flush_worker variant, ~10–27 MB transfers) and reproduce on two unrelated transport sets (dc_x and shm,ib,cuda_ipc,cuda_copy), so it is a UCP-level protocol/lane bug rather than a device or fabric problem. The log also shows the endpoints in use have 6 lanes (RMA BW : 5/6), i.e. more lanes than the fast-path lane array. The freshest master change in exactly that area is [REDACTED:Hex High Entropy String] "UCP/PROTO: Keep latency singles off lanes beyond the fast-path array (#11808)" (Evgeny Leksikov, 2026-08-25 — one day before this run, touching src/ucp/rma): if a large GET is posted on a lane index outside the fast-path array, its completion is never progressed/flushed, which matches a request that never completes and a flush_worker that never returns.

PR #11796 (branch HPCINFRA-4739, "CI: Replace Blue Ocean with pipeline-overview URL") contains no library code, so it cannot produce this hang — it merely inherited a broken master. w1 and w3 show no test failure of their own; they were Aborted by ntsemah@nvidia.com after w0/w2 failed.

Implicated commit: [REDACTED:Hex High Entropy String] — "UCP/PROTO: Keep latency singles off lanes beyond the fast-path array (#11808)", Evgeny Leksikov, 2026-08-25 (most likely; needs bisect confirmation). Not f0fcdd62 (the PR commit under test).

File: src/ucp/rma/get_offload.c / lane-selection helpers in src/ucp/core/ucp_ep.h (fast-path lane accessors); failure surfaces at test/gtest/ucp/test_ucp_memheap.cc:115 and test/gtest/ucp/ucp_test.cc:300.

Suggested fix:

  1. Reproduce standalone and confirm the hang is master-side, not PR-side: ./gtest --gtest_filter='dcx/test_ucp_rma.get_nonblocking/0' on master at [REDACTED:Hex High Entropy String] and at its parent — a two-commit bisect will confirm or clear UCP/PROTO: Keep latency singles off lanes beyond the fast-path array #11808 immediately.
  2. Audit the lane eligibility change in UCP/PROTO: Keep latency singles off lanes beyond the fast-path array #11808: ensure every lane a GET/multi-lane RMA protocol can select is resolvable and progressable — either exclude lanes beyond UCP_MAX_FAST_PATH_LANES consistently from both selection and completion/flush, or resolve them via the non-fast-path ucp_ep_get_lane() accessor instead of the fast-path array. Getting this only half-right yields a posted-but-never-completed request, exactly what the log shows.
  3. Confirm the hypothesis cheaply by re-running the test with UCX_MAX_RMA_LANES=1 (and capturing UCX_PROTO_INFO=y output for the failing size); if the hang disappears with a single RMA lane, the multi-lane/fast-path-array boundary is the culprit.
  4. Revert [REDACTED:Hex High Entropy String] if it reproduces, and add a gtest variant covering >5-lane endpoints with large GET so this boundary is covered in CI.
  5. For PR CI: Replace Blue Ocean with pipeline-overview URL #11796 specifically: rebase onto a fixed master and re-run; do not raise the job time limit — the 3-minute request timeouts and 11-minute silence are a hang, and more wall clock would not help.

Related: PR #11808 (#11808) — suspected regression source; PR #11796 (#11796) — the CI-only PR that merely surfaced it. Adjacent FT/RMA lane work worth reviewing: #11563 (db208ee4), #11765 (0a5fba2c).

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id dce81919-2f84-4f0c-8e85-689fa7d2675b in the triage console for the audit trail.

@svc-ucx

svc-ucx commented Aug 26, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS%2Fucx-dispatcher-oss · commit f0fcdd62

TL;DR: The dispatcher didn't fail on its own — UCX-OSS/ucx-test-dl-gpu-oss #7 hung for 2h09m inside the ucp_client_server stream test (-m host -c stream -s 1) until Jenkins' wall-clock kill, which cancelled the whole parallel block; ucx-test-gpu-oss #8 separately died from a Kubernetes exec-stream i/o timeout. Neither is caused by PR #11796 (a CI URL-string change) — retrigger, and add a timeout around the client/server invocation in contrib/test_jenkins.sh so a hung example fails fast instead of consuming the entire 200-minute budget.

Full analysis

Summary: Dispatcher build #5 reported all 8 downstream stages as ABORTED at an identical ~200 min; 6 succeeded, ucx-test-dl-gpu-oss #7 FAILED due to a hang in the UCP client-server stream test, and ucx-test-gpu-oss #8 ABORTED after a container-streaming infrastructure error.

Root cause: Two independent, unrelated issues, both symptomatic of wall-clock kills rather than real test assertions:

  1. Hang (primary). In ucx-test-dl-gpu-oss File to show options that tell GNU indent to format code as we want. #7, stage 160 "Checkout & test" (duration 8,415,692 ms ≈ 2h20m) produced its last meaningful line at 13:31:46.584:
    + taskset -c 1 ./examples/ucp_client_server -m host -c stream -s 1 -a 127.0.0.1 -p 10510
    Then complete silence for 2h09m26s until 15:41:12.755 Sending interrupt signal to process → Terminated / Timeout has been exceeded. That single gap is essentially the whole remaining runtime, so the process was hung, not slow. Notably the client emitted nothing at all — not even Client: iteration #1, which every preceding am/tag iteration printed within ~0.3 s — so it blocked during connection establishment/wireup or in the first stream send/recv progress loop, on the first stream API case (-s 1) after all am and tag sizes had passed. run_client_server_app uses a bare wait ${client_pid} with no timeout, so the harness blocked indefinitely.
  2. Infra flake (secondary). ucx-test-gpu-oss File to show options that tell GNU indent to format code as we want. #8 failed in x86_64/build_helper_ucx/w0 while compiling gtest objects: Error: error streaming command in container: error reading from error stream: next reader: read tcp 100.106.237.213:33822->10.220.0.21:443: i/o timeout. This is a Kubernetes exec/attach stream drop, not a UCX defect. The pipeline then ran pipeline_stop (scancelling Slurm jobs 85206–85209) and the build was finally hard-killed manually ("Aborted by Noam Tsemah"), which is why every sibling stage shows the same ABORTED/200-min duration.

Implicated commit: None in UCX code. Trigger commit [REDACTED:Hex High Entropy String] / PR #11796 is "CI: Replace Blue Ocean with pipeline-overview URL", a CI URL-string change that cannot affect UCP stream data transfer. examples/ucp_client_server.c has not been touched since 1af57d6 (2024-11-29, rakhmets); the hang is pre-existing/flaky on the aarch64 DL runner.

File: contrib/test_jenkins.sh:188-201 (untimed taskset ... & + wait ${client_pid}); hung workload is examples/ucp_client_server.c on the CLIENT_SERVER_SEND_RECV_STREAM path.

Suggested fix:

  1. Don't block PR CI: Replace Blue Ocean with pipeline-overview URL #11796 on this — re-trigger the dispatcher; the failures are environmental/flaky and unrelated to the diff.
  2. Harden the harness so a hang is diagnosable instead of a 200-min timeout. In run_client_server_app, bound both processes and capture state on hang, e.g.:
    timeout -s ABRT 120 taskset -c $affinity_client ${test_exe} ${test_args} ${server_addr_arg} ${server_port_arg} &
    client_pid=$!
    if ! wait ${client_pid}; then
        echo "ERROR: client hung/failed: ${test_args}"
        gstack ${server_pid} || true   # dump server backtrace before kill
        exit 1
    fi
    Also apply a timeout to the server launch (line 188) so a stuck server can't outlive the case, and consider UCX_LOG_LEVEL=debug on retry for the stream case.
  3. File a separate tracking issue for the stream-API hang on aarch64/dl-base, since the client never reached its first iteration print — focus on ucp_ep_create/wireup completion and the initial ucp_stream_send/ucp_stream_recv progress loop for -s 1.
  4. For the GPU job, treat the container i/o timeout as a known Kubernetes exec-stream flake; the existing retry wrapper should cover it, but consider retrying on that specific error string rather than aborting the parallel block.

Related: PR #11796 — CI: Replace Blue Ocean with pipeline-overview URL (trigger only, not the cause). No existing issue found for the ucp_client_server stream hang.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 74b5e395-b941-43b9-aa9b-53307e976e76 in the triage console for the audit trail.

@svc-nvidia-pr-review

Copy link
Copy Markdown

🤖 Starting review — findings will be posted here when done.

Comment thread .ci/jenkins/Jenkinsfile.dispatcher Resolved
@svc-nvidia-pr-review

Copy link
Copy Markdown

Test/validation coverage note: Consistent with the prior review, this is a CI-config change with no dry-run/CI output demonstrating that the pipeline-overview/ link resolves and that the dispatcher still triggers all eight leaf jobs after the dsl: → pipeline-scm migration. The migration is the higher-risk part (Jenkins loads the script differently), so a green dispatcher run on this PR is worth confirming before merge. Not a blocker.

Replace GitHub commit status links to point to Jenkins'
pipeline-overview page instead of Blue Ocean UI.

Signed-off-by: Noam Tsemah <ntsemah@nvidia.com>
Signed-off-by: Noam Tsemah <ntsemah@nvidia.com>
@svc-nvidia-pr-review

Copy link
Copy Markdown

🤖 Starting review — findings will be posted here when done.

@svc-nvidia-pr-review

Copy link
Copy Markdown

🤖 Review complete — no issues found.

@svc-ucx

svc-ucx commented Sep 2, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-gpu-oss · commit feec90ba

TL;DR: The GPU gtest job hung in rc/test_ucp_rma_reg.get_blocking/2 <rc_v,cuda_copy,rocm_copy/no_devx> — offloaded GET bcopy requests never completed (3× 180 s "request did not complete on time" + data validation failure, then gtest self-aborted), which is unrelated to the CI-only PR under test and points at master commit 84548e4 (#11840) that rewrote the get/bcopy offload completion/restart path.

Full analysis

Summary: Stage x86_64/build_helper_ucx/w0 → Test (node 298) failed with exit code 2: gtest aborted after UCP GET requests hung on the rc_v (rc_verbs) transport.

Root cause: Evidence from the stage log (build #12, node 298):

  • [ RUN ] rc/test_ucp_rma_reg.get_blocking/2 <rc_v,cuda_copy,rocm_copy/no_devx> at 07:23:34 is the last application output; then three silent gaps of ~186 s, 180 s, 180 s each terminated by ucp_test.cc:300 UCX ERROR request 0x... did not complete on time (timestamps 1788333994 / 1788334174 / 1788334354 — exactly 180 s apart), followed by a 12-minute silent gap and test_helpers.cc:57 Failed / Connection timed out - abort testing + Caught signal 6.
  • The gaps are pure inactivity, so this is a hang, not a slow test: three separate GET requests were posted and their UCT completions never arrived, hence also test_ucp_memheap.cc:115: data validation failed (destination buffer never filled).
  • The failing operation is the offloaded GET bcopy/zcopy path on rc_verbs. The only recent change to exactly that code is src/ucp/rma/get_offload.c, commit 84548e4 (2026-08-31, one day before this build), which replaced the get/bcopy completion with ucp_proto_request_restart_or_complete(), added UCP_PROTO_COMMON_INIT_FLAG_FAILOVER to the probe flags, and added a reset handler that rewinds the datatype iterator. Note that in ucp_proto_get_offload_bcopy_completion() the ucp_datatype_iter_cleanup() is done before deciding to restart, and the reset rewinds the iterator while fragments already posted on the wire still hold references to req->send.state.uct_comp — a lost/mismatched completion count there leaves the request permanently un-completed, matching the observed symptom.
  • The PR under test (CI: Replace Blue Ocean with pipeline-overview URL #11796, "CI: Replace Blue Ocean with pipeline-overview URL") touches only CI glue and cannot affect the UCP data path, so this is a master-side regression (or an intermittent one exposed by it), not a PR failure. Build TEST/BUILD: Fix release build #11 of the same job also died (aborted after 8400 s), so the job is already unstable.

Implicated commit: 84548e4 — "UCP/RMA: Support failover for offloaded GET bcopy protocol (#11840)", Evgeny Leksikov (not the PR commit feec90b, which is CI-only)

File: src/ucp/rma/get_offload.c:48-56 (ucp_proto_get_offload_bcopy_completion) and src/ucp/rma/get_offload.c:137-145 (ucp_proto_get_offload_bcopy_reset)

Suggested fix:

  1. Do not raise the job timeout — the process was hung, not slow.
  2. Reproduce locally in a loop: GTEST_FILTER='rc/test_ucp_rma_reg.get_blocking*' ./gtest with UCX_TLS=rc_v and the no_devx variant (UCX_IB_MLX5_DEVX=n), with UCX_LOG_LEVEL=req to confirm uct_comp.count never reaches zero.
  3. In ucp_proto_get_offload_bcopy_completion(), only clean up the datatype iterator on the terminal (complete) path, and make the restart path re-initialize req->send.state.uct_comp (count/status) consistently with the rewind done in ucp_proto_get_offload_bcopy_reset(); assert that UCP_REQUEST_FLAG_PROTO_INITIALIZED is cleared so ucp_proto_completion_init() runs again after a reset.
  4. Ping the author of UCP/RMA: Support failover for offloaded GET bcopy protocol #11840; if the hang reproduces on plain master, revert 84548e4 (or gate the new failover path behind UCP_ERR_HANDLING_MODE_FAILOVER only) to unblock CI, then re-run PR CI: Replace Blue Ocean with pipeline-overview URL #11796's CI, which is unaffected.

Related: #11840 (implicated change), #11796 (PR under test, CI-only), earlier failover work #11266 and #11162

@svc-ucx

svc-ucx commented Sep 2, 2026

Copy link
Copy Markdown

🤖 CI Triage Agent — UCX-OSS/ucx-test-dl-gpu-oss · commit feec90ba

TL;DR: The build was not slow — it hung: ./examples/ucp_client_server -m host -c stream -s 1 (first STREAM-API case) produced zero output for 2h09m until Jenkins killed the job at the 140-min wall clock. The hang is in the UCP stream client/server example on the aarch64 DL-GPU node, unrelated to PR #11796 (a CI-URL-only change); run_client_server_app also needs a timeout so a hang fails fast instead of burning the whole job.

Full analysis

Summary: Stage Checkout & test (node 160) of UCX-OSS/ucx-test-dl-gpu-oss #10 was ABORTED after 8,409,980 ms because the ucp_client_server STREAM-API smoke test hung forever.

Root cause: From the stage log, all am and tag msg_size cases (1/16/256/4096/65534) passed normally, each finishing in ~15 s. Then:

  • 07:18:13.613 server: server is listening on IP 0.0.0.0 port 10510
  • 07:18:28.494 + taskset -c 1 ./examples/ucp_client_server -m host -c stream -s 1 -a 127.0.0.1 -p 10510
  • next line: 09:27:49.307 Sending interrupt signal to process → Timeout has been exceeded

That is a 2 h 09 min gap with zero output — by far the largest gap in the log and essentially the whole runtime. The client never even printed Client: iteration #1 (which appeared within ~0.3 s in every preceding am/tag case), so it blocked inside the stream connect / ucp_stream_recv+worker-progress loop before the first iteration, on loopback 127.0.0.1 on the aarch64 dl-base image. This is a hang, not insufficient time.

A contributing CI defect: run_client_server_app() uses a bare wait ${client_pid} with no timeout, so any client hang consumes the entire job wall clock instead of failing quickly with a diagnosable error.

The PR under test (#11796 "CI: Replace Blue Ocean with pipeline-overview URL", branch HPCINFRA-4739, commit feec90b) only changes a Jenkins URL and cannot affect the UCP stream path — so the hang is a pre-existing/environmental flake, not introduced by this PR.

Implicated commit: unknown — not caused by [REDACTED:Hex High Entropy String] (CI-URL-only change). examples/ucp_client_server.c last changed 2024-11-29 (1af57d6, rakhmets), so no recent example regression either.

File: contrib/test_jenkins.sh:198-201 (untimed taskset ... & + wait ${client_pid}); hung binary is examples/ucp_client_server.c STREAM path (-c stream).

Suggested fix:

  1. Make hangs fail fast and self-diagnose — wrap the client (and server) launch in timeout, e.g. in run_client_server_app:
    timeout -s ABRT 300 taskset -c $affinity_client ${test_exe} ${test_args} ${server_addr_arg} ${server_port_arg} &
    client_pid=$!
    wait ${client_pid} || { echo "FAILED: client hung/failed for '${test_args}'"; gstack ${server_pid} || true; exit 1; }
    This converts a 140-minute wall-clock kill into a ~5-minute failure with usable output.
  2. Re-run the job to confirm flakiness; if the stream case reproduces on aarch64/dl-base, capture UCX_LOG_LEVEL=debug UCX_PROTO_INFO=y plus a gdb/gstack backtrace of the stuck client to identify which transport/protocol the stream path selects on that image.
  3. Since PR CI: Replace Blue Ocean with pipeline-overview URL #11796 only touches a CI URL, this failure should not block it — retrigger and open a separate tracking issue for the stream-example hang on the aarch64 DL-GPU node.

Related: PR #11796 (build under test, CI-only change); no existing issue found for a ucp_client_server stream hang — worth filing one.

🛡️ This comment had 1 potential secret(s) redacted (Hex High Entropy String). See request_id 3b5a6687-1931-4bdb-a357-5285efb34ab2 in the triage console for the audit trail.

@ntsemah
ntsemah requested a review from dpressle September 2, 2026 10:27
@ntsemah

ntsemah commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

The Jenkins builds were triggered by ucx-dispatcher-oss-test, a test dispatcher job running with this PR's changes.

@Alexey-Rivkin
Alexey-Rivkin merged commit da18d11 into openucx:master Sep 6, 2026
15 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants