---
id: "bug-1757"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "worker"
severity: "unknown"
timestamp: "2026-09-02T02:45:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/worker/src/resource_sync.c"]
tags: ["worker-rejoin-resync", "task-4.4", "resource_sync-c", "init_builtin_load_indices", "collect_load_indices", "stale-guard", "test-lifecycle", "companion-fix"]
related: ["bug-1756"]
legacy: true
---

# bug-1757: worker-rejoin-resync task 4.4 (resource_sync.c): after fixing bug-1756's double-join abort, the…

## Description
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.

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## 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.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1756