lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(worker-rejoin-resync): task 4.4 - gate periodic load-indices send on resync_pending

Browse source 
Extends task 4.3's post-join gating to resource_sync_thread()'s
independent periodic reporting pthread, closing the Requirement 3.8 gap
where load-indices sends could interleave with an in-flight job-state
reconciliation report. Also fixes two pre-existing latent bugs
(bug-1756, bug-1757) in resource_sync.c that blocked a truthful RED/GREEN
signal for the new tests.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ypUeKgbAqLWUkaSJ79poN
This commit is contained in:
Rongsong Shen 2026-09-02 03:01:56 +00:00
parent 4140ecdbae
commit b6a2f5ec14
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
4 changed files with 241 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

52
.wolf/buglog.json
View file

@ -20610,6 +20610,58 @@
],
"occurrences": 1,
"last_seen": "2026-09-02T00:30:00Z"
},
{
"id": "bug-1756",
"timestamp": "2026-09-02T02:40:00Z",
"error_message": "worker-rejoin-resync task 4.4 (Requirement 3.8, resource_sync.c): AddressSanitizer abort \"Joining already joined thread, aborting.\" while building the task's own new resync_pending-gate tests for resource_sync_thread(). Discovered live: the new tests are the first callers ever to exercise resource_sync_create()/resource_sync_start()/resource_sync_stop()/resource_sync_destroy() as a full lifecycle from a test binary (the two pre-existing tests only ever called collect_load_indices() directly). Each test calls resource_sync_stop(sync) then resource_sync_destroy(sync) back-to-back -- the exact same sequence xcecd.c's own real shutdown path (xcecd_cleanup(), src/worker/src/xcecd.c:580-582) already uses in production.",
"file": "src/worker/src/resource_sync.c",
"root_cause": "resource_sync_stop() calls pthread_join(sync->thread, NULL) but never resets sync->thread to 0 (or any invalid sentinel) afterward. resource_sync_destroy() unconditionally calls resource_sync_stop() again as its first action, with no guard on whether the module was already stopped -- so a caller pattern of stop() then destroy() (used verbatim by both xcecd_cleanup() in production and the new task 4.4 tests) pthread_join()s the same already-joined thread handle a second time. This is undefined behavior; under ASAN it aborts hard instead of silently misbehaving. connection_handler.c's analogous network_handler_destroy() already guards its own equivalent second stop call with `if (handler->running)`, showing this exact hazard is a known pattern elsewhere in the same daemon that resource_sync.c's destroy simply never adopted.",
"fix": "FIXED (2026-09-02, worker-rejoin-resync task 4.4, in-boundary companion fix -- resource_sync.c was already in this task's file boundary and the double-join blocked the task's own new tests from ever completing). resource_sync_destroy() now guards its internal resource_sync_stop() call with `if (atomic_load(&sync->running))`, mirroring network_handler_destroy()'s established idiom exactly -- if the caller already stopped the module explicitly, destroy() no longer re-joins the same thread handle. Verified via 5 consecutive full runs of the rebuilt resource_sync_test binary under ASAN: 5 Tests, 0 Failures each run, no abort (previously deterministic abort on the very first run reaching a stop()+destroy() pair). Full worker suite (meson test --suite worker) also green: 7/7 OK, no regressions, including controller_connector_test and xcecd_resync_test (task 4.3's own suites).",
"tags": [
"worker-rejoin-resync",
"task-4.4",
"resource_sync-c",
"resource_sync_destroy",
"resource_sync_stop",
"asan",
"double-join",
"pthread",
"thread-lifecycle",
"companion-fix",
"requirement-3.8",
"fixed"
],
"related_bugs": [
"bug-1519",
"bug-1757"
],
"occurrences": 1,
"last_seen": "2026-09-02T02:40:00Z"
},
{
"id": "bug-1757",
"timestamp": "2026-09-02T02:45:00Z",
"error_message": "worker-rejoin-resync task 4.4 (resource_sync.c): after fixing bug-1756's double-join abort, the same new resync_pending-gate tests still failed deterministically -- \"No load indices to report\" logged, and both test_resource_sync_thread_resumes_load_indices_send_once_resync_clears and test_resource_sync_thread_sends_load_indices_normally_when_not_pending failed asserting the load-indices send call count stayed 0. Both tests run AFTER an earlier test in the same binary has already completed a full resource_sync_create()/start()/stop()/destroy() cycle.",
"file": "src/worker/src/resource_sync.c",
"root_cause": "init_builtin_load_indices() guarded its own body with a function-local `static bool initialized` that, once set true, permanently no-ops the function for the rest of the process -- but resource_sync_destroy() -> resource_sync_cleanup_load_indices() frees g_load_indices and resets it to NULL on every destroy. collect_load_indices() (the function's only caller) already re-checks `if (g_load_indices == NULL) { init_builtin_load_indices(); }` before every collection, correctly wanting to re-populate the registry after a destroy -- but the stale `initialized` static silently blocked that re-population forever after the first create/destroy cycle in a process, leaving g_load_indices permanently NULL/empty (a pure test-lifecycle gap: the real daemon calls resource_sync_create() exactly once per process lifetime, so it never previously exercised a second populate-after-teardown cycle).",
"fix": "FIXED (2026-09-02, worker-rejoin-resync task 4.4, in-boundary companion fix, same file as bug-1756 and blocking the same new tests). Removed the redundant function-local `static bool initialized` guard from init_builtin_load_indices() entirely -- its only caller, collect_load_indices(), already provides the exact same one-time-per-populated-window guarantee via its own `g_load_indices == NULL` check, and no other call site exists (grepped) and no concurrent caller (collect_load_indices() runs only on resource_sync_thread()'s single dedicated pthread in production, or single-threaded test code). Verified via 5 consecutive full runs of the rebuilt resource_sync_test binary: 5 Tests, 0 Failures each run (previously deterministic 1-2 failures on tests running after the first create/destroy cycle). Full worker suite green: 7/7 OK.",
"tags": [
"worker-rejoin-resync",
"task-4.4",
"resource_sync-c",
"init_builtin_load_indices",
"collect_load_indices",
"stale-guard",
"test-lifecycle",
"companion-fix",
"fixed"
],
"related_bugs": [
"bug-1756"
],
"occurrences": 1,
"last_seen": "2026-09-02T02:45:00Z"
}
]
}