myxce/.wolf/bugs/bug-1909.md

id	status	status_updated	status_note	component	severity	timestamp	last_seen	occurrences	files	tags	related	fix_commits
bug-1909	fixed	2026-10-03		tooling	wrong-result	2026-10-03T08:09:49Z	2026-10-03T08:09:49Z	1	src/tools/test-version-startup-consistency.sh	test-script version dirty-fingerprint scheduler		ef6e562c

bug-1909: test-version-startup-consistency.sh scheduler check fails on any dirty tree (fingerprint vs -dirty)

Description

Observed:

FAIL [scheduler]: commit id MISMATCH ('ac7a4385-f4637557' vs 'ac7a4385-dirty')

src/tools/test-version-startup-consistency.sh compares the scheduler's --version commit id with the one in its startup log line. On a dirty working tree --version reports a content fingerprint (<sha>-<fingerprint>) while the startup log keeps <sha>-dirty, so the scheduler check fails.

Expected: the script passes on a dirty tree. The dirty-fingerprint feature keeps the startup log at -dirty on purpose (its own regression script, test-dirty-fingerprint-startup-log-unchanged.sh, asserts that), so the consistency check should compare the two forms accordingly (e.g. compare the base sha, or accept -dirty in the log when --version carries a fingerprint). Impact: the script can only pass from a clean tree; any developer machine with uncommitted changes (here .wolf/, .claude/, data/) sees a false failure. Test-only; product binaries behave as designed. Found by: spec task (controller-peers-env-fallback task 5.2)

Environment

• OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
• libc: glibc 2.42-47 (interpreter /nix/store/wb6rhpznjfczwlwx23zmdrrw74bayxw4-glibc-2.42-47/lib/ld-linux-x86-64.so.2)
• Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
• Build: asan (xce.build)
• Code: scheduler-framework @ ac7a4385-dirty
• Deployment: n/a — the script builds and runs the scheduler locally, no cluster

Reproduction

1. From a working tree with any uncommitted change (e.g. echo x >> README.md in a scratch worktree at HEAD), run bash src/tools/test-version-startup-consistency.sh.
2. Observe FAIL [scheduler]: commit id MISMATCH ('<sha>-<fingerprint>' vs '<sha>-dirty').

• Frequency: deterministic on any dirty tree (reproduced 2026-10-03 with HEAD's unmodified script in a scratch worktree with one README edit); passes on a clean tree.
• Evidence: not kept (the script deletes its work dir on exit). Separately, the script's apiserver go build fails on this machine with "module lookup disabled by GOPROXY=off" (no Go module cache) — unrelated environment limitation.

Root cause

check_consistency() in src/tools/test-version-startup-consistency.sh (written for build-time-versioning Req 2.2) requires the --version and startup-log commit ids to be byte-identical. The later dirty-content-fingerprint feature deliberately made --version show <sha>-<8-hex fingerprint> on a dirty tree while the startup log keeps <sha>-dirty (its requirements.md scope note and Req 3.2 call this a scoped exception), but this script was never updated, so it fails on any dirty tree.

Fix

check_consistency() now treats exactly that pairing as agreement: --version matching ^(.+)-[0-9a-f]{8}$ and the startup log equal to <same sha>-dirty (the fingerprint is sha256sum | cut -c1-8, xce-build.sh). Anything else is still compared byte-for-byte. Self-test cases (e) (pairing accepted) and (f) (different sha, or a fingerprint against a clean log, rejected) added to demonstrate_detection_capability(); header, PASS line and final banner reworded.

Verification

• Test: demonstrate_detection_capability() case (e) in src/tools/test-version-startup-consistency.sh — RED before the fix (extracted harness: FAIL [DEMO-dirty-fingerprint-pairing]: commit id MISMATCH), GREEN after; cases (a)-(c), (f) still reject.
• Suites: bash src/tools/test-version-startup-consistency.sh exit 0 on a dirty tree ([scheduler] --version fingerprint '66520e6b-a46c0a00' pairs with startup log '66520e6b-dirty'), 2026-10-03; xce-build.sh all --incremental (asan) green.
• Live: n/a (test-script defect)

References

• Related: none