Skip to content

probe: run the ubuntu 4/4 shard against an unchanged integration/remote (do not merge) - #796

Closed
fujibee wants to merge 1 commit into
integration/remotefrom
probe/769-base-ubuntu-4of4
Closed

probe: run the ubuntu 4/4 shard against an unchanged integration/remote (do not merge)#796
fujibee wants to merge 1 commit into
integration/remotefrom
probe/769-base-ubuntu-4of4

Conversation

@fujibee

@fujibee fujibee commented Aug 14, 2026

Copy link
Copy Markdown
Owner

Declared reviewers: 0

Measurement only. Do not merge — this is closed as soon as the shard reports.

What this measures

Whether bats (ubuntu-latest 4/4) fails on integration/remote with no change applied, which is the one thing nobody has been able to observe tonight.

Three PRs (#775, #792, #794) fail that shard. On #792 the same SHA was re-run and failed again with the same assertion — not ok 265 watch: relaunch with the SAME instance id replaces the previous watcher (#66 preserved) — so it is not a flake by that discriminator. fujibee/agmsg#769 says the base reproduces it standalone, but that measurement is from 2026-08-13 and has not been repeated since.

Why a pull request, and why not a doc

  • tests.yml runs on push: [main] and pull_request: [main, integration/remote]. A push to integration/remote does not run the matrix — that branch's runs are verify-versions only. There is no branch history of this shard to read.
  • The assertion does not reproduce on a macOS machine: a clean checkout of d0b762d passes it locally. So a local run cannot see this failure at all.
  • The change is a comment in a shell file. A docs-only diff makes the workflow skip the suite and report the shard green anyway#776's bats (ubuntu-latest 4/4) shows conclusion=success with Run bats suite (this shard) skipped. That green was used as evidence tonight, and it had measured nothing.

Reading the result

ubuntu 4/4 red    the base reproduces it; the three branches are not the cause
ubuntu 4/4 green  the base is healthy; the three reds belong to their branches

Either answer settles it. Both are recorded on #769 afterwards, along with the re-run result and the fact that #776 was not a measurement.

Controls already taken

bats (ubuntu-latest 4/4) has run and passed on this lineage — #765 (1743dc8) and #766 (9b05e7a) both show step 9 executed with conclusion=success. So the shard is not uniformly red on ubuntu, which is why the current base has to be measured rather than assumed.

Not for merge. A comment in a shell file, and nothing else.

tests.yml runs on pull requests only, so a branch push cannot exercise the
matrix, and the failing assertion in that shard does not reproduce on a macOS
machine. The shard therefore cannot be observed against the base by any means
available here except opening a pull request.

A shell file rather than a doc: the workflow skips the suite on a docs-only
diff and reports the shard green anyway, which is how a green with no
measurement behind it got used as evidence tonight.

Closed without merging once the shard has reported.
@fujibee

fujibee commented Aug 14, 2026

Copy link
Copy Markdown
Owner Author

Result: bats (ubuntu-latest 4/4) SUCCESS, on head d59eb9d1b7e77ddcc8d2f82b468ac3635d5b58bc, job 94757877451, run 31797547923, attempt 1.

The suite genuinely ran — this is the control that #776 failed:

 3 skipped  Docs-only change — skipping suite
 9 success  Run bats suite (this shard)

What this does and does not say

It says: run on its own, this base passed that shard once. n=1.

It does not say the base is healthy. A single green cannot say that about an assertion whose own issue (#769) calls it intermittent on CI, and three PRs based on this same commit were failing it within the hour. One sample settles nothing about a race.

What it does remove is the reading that the shard is unconditionally red on integration/remote — which was the reading about to be used to land three PRs over it.

Also worth recording

bats (ubuntu-latest 4/4) has run and passed on this lineage before: #765 (1743dc8) and #766 (9b05e7a) both show step 9 executed with conclusion=success. #767, #768 and #776 show step 9 skipped — docs-only diffs, reported green without running anything.

That is a separate defect and it is filed separately: a skipped suite and a passing suite are the same colour on the required check.

Closed without merging

PROBE-769.md never reached this branch — a second commit moving the no-op out of scripts/watch.sh (the script the failing assertion drives) was prepared and deliberately not pushed, because the measurement was already in hand and pushing it would have started another CI run on an already-loaded queue. What ran is the watch.sh comment version, and a comment cannot make a failing assertion pass.

The next measurement is a real fix rather than another probe: _wait_pidfile's window, ported from #758 to integration/remote.

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.

1 participant