From 176f0cf8359e796449c3f8be9b53f0598697789a Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Thu, 20 Aug 2026 16:24:02 +0000 Subject: [PATCH] chore(wolf): checkpoint buglog.json (989 bugs) --- .wolf/buglog.json | 62 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/.wolf/buglog.json b/.wolf/buglog.json index e00bb40e..30608644 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -17848,6 +17848,68 @@ ], "occurrences": 1, "last_seen": "2026-08-20T10:27:00.000Z" + }, + { + "id": "bug-1606", + "timestamp": "2026-08-20T16:00:00Z", + "error_message": "grep: invalid option -- 'P' (BusyBox usage dump) when a standalone .sh script (run via `bash script.sh`, not typed as an inline Bash-tool command) calls `grep -oP '...\\K...'`", + "file": "src/tools/test-version-startup-consistency.sh", + "root_cause": "This coding-agent harness's interactive shell shadows plain `grep` with a `.bashrc`-sourced shell FUNCTION that shells out to a PCRE-capable (ugrep-backed) binary -- but that function is interactive-shell-only and is NOT inherited by a script invoked as `bash script.sh` (a separate, non-interactive process), which falls back to the real `grep` on PATH: BusyBox in this environment, with no -P/PCRE support at all. `grep -oP '(?<=x)y'` typed directly as a Bash-tool command therefore worked fine, masking the incompatibility until the same call was placed inside a committed script file and run standalone.", + "fix": "Replaced the grep -oP '\"gitCommit\":\\s*\"\\K[^\"]*' style extraction with POSIX BRE `sed -n 's/.*\"gitCommit\":[[:space:]]*\"\\([^\"]*\\)\".*/\\1/p'`, which BusyBox sed supports. General rule: any shell script meant to be run standalone (not just typed inline) must assume POSIX-only grep/sed (BRE, -E, -F, -o) -- no -P/PCRE, no lookbehind/\\K.", + "tags": [ + "bash", + "grep", + "busybox", + "sandbox", + "portability", + "sed", + "build-time-versioning" + ], + "related_bugs": [], + "occurrences": 1, + "last_seen": "2026-08-20T16:00:00Z" + }, + { + "id": "bug-1607", + "timestamp": "2026-08-20T16:15:00Z", + "error_message": "`git status` showed src/frontend/apiserver/go.sum modified (+65 lines) after a direct `go build ./cmd/main.go` invocation that never touched go.mod and produced a successful, working binary -- no warning or error printed by the build itself", + "file": "src/frontend/apiserver/go.sum", + "root_cause": "A plain `go build` (default `-mod` setting, `go env GOFLAGS` confirmed empty) blocks go.mod EDITS under Go 1.16+'s readonly-by-default policy, but does NOT by itself block go.sum EXTENSION for modules already implied by go.mod's requirements -- resolving the full module graph for cgo-enabled apiserver added ~65 unrelated indirect-dependency /go.mod-hash-only lines to the committed go.sum as a silent side effect.", + "fix": "Pass `-mod=readonly` explicitly on every direct `go build` invocation against this repo (src/tools/test-version-startup-consistency.sh's apiserver build step). Confirmed live: the identical build still succeeds under explicit -mod=readonly with zero go.sum diff, so nothing was genuinely missing -- the extra entries were pure side effect of the laxer default. Reverted the accidental go.sum change via `git checkout -- src/frontend/apiserver/go.sum` before re-running with the fix.", + "tags": [ + "go", + "go.sum", + "go-modules", + "build", + "side-effect", + "build-time-versioning" + ], + "related_bugs": [], + "occurrences": 1, + "last_seen": "2026-08-20T16:15:00Z" + }, + { + "id": "bug-1608", + "timestamp": "2026-08-20T15:57:00Z", + "error_message": "`xce-build.sh apiserver ` (meson -> go_build custom_target) hung indefinitely (8-10+ minutes, zero progress) building xcecli's Go dependencies; no error, no timeout, just stuck", + "file": "src/tools/go_build", + "root_cause": "go_build hardcodes `GOPROXY=https://goproxy.cn` plus a FRESH, per-invocation GOCACHE/GOPATH under meson's own $TMPDIR sandbox, bypassing the shell's already-populated default $GOPATH/pkg/mod module cache entirely. Confirmed via `ss -tnp` that the resulting `go` process had an ESTABLISHED (not refused/reset) TCP connection to 8.45.176.179:443 (=goproxy.cn, independently reachable fine via plain curl/`/dev/tcp` from the same shell) sitting in futex_do_wait with near-zero CPU time -- a genuinely stuck data path in this sandbox's networking for that specific fresh-cache+custom-GOPROXY combination, not mere slowness (never progressed no matter how long left running across 3 separate attempts). A plain `go list -m all` from an ordinary `nix develop` shell (no wrapper, default cache) resolved the identical apiserver module graph in under a second.", + "fix": "Workaround only (go_build/Makefile NOT modified -- this is a sandbox-specific networking quirk, not a real defect in those files, and out of this task's scope to fix): for a standalone real apiserver/xcecli build in this sandbox, invoke `go build` directly against the default (already-populated) module cache with `GOPROXY=off` plus the same CGO_CFLAGS/CGO_LDFLAGS pkg-config derivation apiserver's own meson.build/test-backend already use (see bug-1597's documented fix for the exact derivation), instead of routing through xce-build.sh apiserver / go_build / make build-server. Diagnose a suspected hang via `ss -tnp` + `/proc//wchan` before assuming it just needs more time.", + "tags": [ + "go", + "go_build", + "goproxy", + "network", + "hang", + "sandbox", + "meson", + "build-time-versioning" + ], + "related_bugs": [ + "bug-1597" + ], + "occurrences": 1, + "last_seen": "2026-08-20T15:57:00Z" } ] }