4 Commits

Include renames

Author	SHA1	Message	Date
3 people	54b662ff96	fix(ci): raise the sdk-java test-lane lock wait above the longest hold (#15257) ... * fix(ci): raise the sdk-java test-lane lock wait above the longest hold (#15243) Co-authored-by: Qwen-Coder <[email protected]> * docs(ci): restate sdk-java lock wait sizing and lane budgets (#15243) * fix(ci): pin the sdk-java lock fallback minutes and restate sizing (#15243) The bare-lock fallbacks hand-write their timeout line, so raising `flock --wait` could leave `160 minutes`/`90 minutes` stale with every test green; pin both literals. The sizing comments also cited a pre-#15128 run as evidence for a sibling-hold chain and repeated an uncited 925 s hold; frame that run as the history it is, state that 9600 s is headroom sized from the hold length rather than an observed chain, and keep the derivation in the design doc's Goals. --------- Co-authored-by: Qwen Autofix <[email protected]> Co-authored-by: Qwen-Coder <[email protected]>	2026-10-24 09:25:45 +00:00
4 people	438bcb2a8f	fix(ci): let the fast Java tier overtake waiting full-tier lock tickets (#15035) ... * fix(ci): serve the fast Java tier before full-tier lock holds (#15032) Co-authored-by: Qwen-Coder <[email protected]> * fix(ci): keep a parked lock head's ticket alive under fast priority A head blocked in `flock --wait` could not touch its ticket, so once a hold outlasted the 1800s mtime arm another waiter reaped a live head and the next ticket, whatever its class, parked in the kernel too. With two classes that lets normal tickets take kernel positions ahead of fast tickets that arrive later during a long hold. A keepalive now refreshes the parked head's ticket at the waiters' two-second cadence; it closes the lock fd and uses `touch -c`, so it can neither hold the lock nor recreate a removed ticket. The ordering and promotion cases used a stub whose `--wait` returned every 200 ms, so they exercised a head that loops, which production never does. They now park `--wait` until release and assert the reachable paths: a fast ticket overtaking a normal ticket that is still waiting, and a promoted waiting normal ticket preceding a later fast ticket. The comments and design docs no longer claim a fast job waits at most the hold already running (a parked head still goes first) or cite #14962/#15032 as fast-behind-full evidence; they state what priority removes and that a single hold longer than the budget is outside it. --------- Co-authored-by: Qwen Autofix <[email protected]> Co-authored-by: Qwen-Coder <[email protected]> Co-authored-by: wenshao <[email protected]>	2026-10-22 03:54:27 +00:00
易良	f036ab2360	fix(ci): name the sdk-java host lock holder when a ticket starves (#15031) ... Three main runs went red today (2026-10-21) with 'host lock not acquired within 90 minutes as queue ticket N; head of queue is N-...': the starved waiter WAS the head of the ticket queue, so the flock is held by an unticketed process -- a stray left by a canceled job, the bare-flock fallback of a resumed release tag, or another machine sharing the runner HOME. The current log cannot name any of them, and each occurrence costs a 90-minute lane plus a flaky-red main. Add best-effort holder diagnostics around the existing queue, with no change to ticket, timeout, or error-signature semantics: the first time the head fails a lock probe it prints a one-shot ::warning:: with the holders visible via lslocks (fuser fallback), and the timeout error now lists the holder under the unchanged ::error:: line. An empty answer means the holder lives on another machine sharing this HOME, which is itself the topological evidence needed for the follow-up fix.	2026-10-21 22:42:13 +08:00
3 people	976425cdb9	fix(ci): queue the sdk-java host lock first-come-first-serve (#14743) (#14912) ... * fix(ci): queue the sdk-java host lock first-come-first-serve (#14743) flock(2) does not order its wakeups, so under continuous arrivals one waiter can lose every release and die at the wait budget — repeatedly burning 40, then 60, then 90 minutes per starved lane across at least three hosts. Replace the inline flock --wait at all three acquisition sites with a ticketed queue: every acquirer takes the next sequence number atomically, only the head of line retries the lock, dead owners are reaped, and the lock still releases at the step boundary. The pinned infrastructure-signature error text is preserved. The .size-baseline records the workflow's new size (smaller than main's, but main itself already exceeds its recorded baseline). * fix(ci): block the queue head instead of polling the lock The first live run starved its full 5400 s budget as queue ticket 1: the head polled flock --nonblock while main and older branches still run blocking flock --wait, so every release went to a legacy waiter's kernel wakeup. The head now blocks in five-second slices, re-entering the same wake race on even terms; tickets still order every run that uses this helper. * fix(ci): serve the fast tier before full-tier holds The queue bounded the wait by position but a fast-tier PR job still queued behind every full-tier hold ahead of it. Give the fast tier its own class: the head is the first sorted ticket and fast tickets sort first, so a PR job waits at most the hold already running. A normal ticket ages into the fast class after 20 minutes, so continuous PR traffic cannot starve the full tier. * refactor(ci): keep the lock queue plain FIFO. Drops the priority/aging classes: a single first-come-first-serve line is simpler to review and reason about. The head still blocks in five-second slices so it re-enters the kernel wake race on even terms with legacy waiters, and dead owners are still reaped. The tradeoff is explicit: a fast-tier job waits its turn behind full-tier holds instead of jumping them. * fix(ci): stop leaking the host-lock ticket and reap stale orphans Three bounded defects in the fair-lock helper, all confirmed by executing it rather than by reading alone: - The EXIT/TERM/INT traps quoted `${ticket}`, a `local` that is already out of scope once the sourcing step's shell exits, so every trap ran `rm -f ''` and each successful acquisition left its head ticket behind. Drop the traps and leave the queue at acquisition instead: a holder needs no place in line once the kernel holds the lock, and SIGKILL runs no trap. - The ticket was published after `exec 8>&-` released the counter lock, so a later arrival could take seq+1, see an empty queue, name itself head and win the lock out of arrival order. Publish inside the critical section. - Orphan liveness was decided solely by `kill -0`, so a ticket whose PID had been recycled to a live process was never aged out and, being head, made an idle lock unreachable for every job on the host. Age a ticket out on mtime alone above 1800s; a live waiter re-touches every ~7s. Measured on a free lock with a live-PID, 2h-old orphan head ticket: base burns its full 6023ms budget and exits 1 with the orphan intact; this commit acquires in 19ms and reaps it. Co-authored-by: Qwen-Coder <[email protected]> Patrol-Run: qwen-pr-closeout/jmvhb9cysmc * style(ci): keep only the load-bearing why in the lock helper comments Co-authored-by: Qwen-Coder <[email protected]> Patrol-Run: qwen-pr-closeout/jmvhb9cysmc * fix(ci): keep the lock queue head in one blocking wait The head re-entered the kernel wait queue every five seconds, so a release reached waiters that stayed blocked first; the head could lose every release and starve to its budget. Run 39472038337 still burned the full 5400 s as queue ticket 2. Wait once for the remaining budget and log the remaining time at most once a minute. A resumed release tag can predate the helper, so both acquisition sites fall back to the bare lock instead of dying before Maven and wedging the release. Pin the emitted ::error:: annotation prefix rather than a file substring a comment can satisfy, and observe the real acquisition order in the stub. * fix(ci): name the blocking ticket in the sdk-java lock timeout The timeout line reported only the dying waiter's own ticket, so a deep queue and a wedged one produced the same message and neither could be acted on from the log. Name the head of line, which separates a real sibling hold from an orphan ticket. Bring both design docs back to the shipped mechanism: two acquisition sites, the flock'd counter with no aging path, the 1800 s mtime arm and the ticket removed at acquisition, plus the operator recovery command. Refresh the stale .size-baseline entry for sdk-java.yml. * test(ci): wait for the first ticket instead of a fixed sleep The FIFO case started the second acquirer 800 ms after the first and relied on that being enough for A to take sequence 1. On a loaded runner it is not, and B wins sequence 1, so the case fails on timing rather than behavior. Poll for A's published ticket instead. * fix(ci): print the lock wait line before blocking The wait line was emitted only after `flock` returned, so a head parked behind a sibling hold printed nothing for its whole budget: run 39528681869's step sat in flock for 40 minutes and was cancelled with an empty log, which is the opposite of the attribution this change exists to add. Probe with --nonblock, print the ticket line, then block. The observability bullet in both design docs now states what the code does. --------- Co-authored-by: Qwen-Coder <[email protected]> Co-authored-by: Shaojin Wen <[email protected]>	2026-10-21 12:21:44 +08:00