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

docs(worker-rejoin-resync): add task 4.4 - close feature-level Req 3.8 gap

Browse source 
kiro-validate-impl's requirements-coverage check found AC 3.8 only
partially satisfied: resource_sync.c's independent periodic thread
(load-indices RPCs, every 15s) is never gated by resync_pending, so
it can fire mid-reconciliation - task 4.3's gate only covered
checking_connection()'s rejoin_call(). NO-GO with this as the sole
concrete remediation item; adding task 4.4 to close it before
re-validating.

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

8
.kiro/specs/worker-rejoin-resync/tasks.md
View file

@ -104,6 +104,14 @@
- _Boundary: xcecd_resync.c_
- _Depends: 4.2_
- [ ] 4.4 Gate the worker's other periodic background reporting on the same resync_pending flag
- Close a Requirement 3.8 gap found by feature-level validation, missed by task 4.3's own boundary: `checking_connection()`'s `rejoin_call()` is not the worker daemon's only periodic post-join activity — `src/worker/src/resource_sync.c`'s `resource_sync_thread()` is a separate pthread, started once at daemon init (unrelated to any join event), that periodically (every `LOAD_INDICES_INTERVAL_DEFAULT`, 15s) sends live `xcecd_send_load_indices()`/`xcecli_update_resvals()` RPCs to the controller over the same connection used for the resync exchange, with zero reference to `resync_pending`/`xcecd_resync_is_pending()` anywhere in that file — confirmed by inspection
- Make the periodic load-indices send check `xcecd_resync_is_pending()` first, the same way `checking_connection()`'s `rejoin_call()` already does (task 4.3), and skip/defer that cycle's send while a reconciliation report is still in flight — the send is already periodic, so a skipped cycle is naturally retried on the next tick, no new retry/queueing mechanism needed
- Observable completion: a load-indices send that would otherwise fire while `resync_pending` is set is observed not to fire during that window, and resumes firing on its normal periodic cadence once the flag clears; the existing periodic cadence and behavior when no reconciliation is in flight are unchanged
- _Requirements: 3.8_
- _Boundary: resource_sync.c_
- _Depends: 4.3_
- [x] 5. (P) Core: exclude a reconciling host from scheduler dispatch candidacy
- Extend the scheduler's existing candidate-host filter so a host currently undergoing job-state reconciliation is excluded from dispatch candidacy the same way an already-unavailable host is
- When the reconciling status clears, the same filter must stop excluding that host without any separate action