Rongsong Shen
0f7699deba
Requirements and design approved (design fixed the fork()-vs-posix_spawn mutex-inheritance-deadlock risk product.md's own "no fork() for snapshots" decision already rejected); tasks generated but never approved. Superseded by xce-node-manager after the user decided the controller should not directly own spawning/killing its own scheduler process -- a new per-node xce-node-manager component takes over that responsibility instead. Kept in place as a reference (notably the fork()-vs-posix_spawn analysis); this spec's tasks.md must not be implemented (see spec.json's superseded_note). Checkpointing uncommitted spec work found in this shared worktree. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAWMhfRJFnmmnG8h97yUDd
26 lines
4.4 KiB
JSON
26 lines
4.4 KiB
JSON
{
|
|
"feature_name": "scheduler-primary-lifecycle",
|
|
"created_at": "2026-09-02T04:39:22Z",
|
|
"updated_at": "2026-09-02T07:25:03Z",
|
|
"language": "en",
|
|
"phase": "superseded",
|
|
"superseded_by": "xce-node-manager",
|
|
"superseded_note": "2026-09-02: after further discussion, the user decided the controller should not directly own spawning/killing its own scheduler process. Instead, a new general per-node xce-node-manager component (one per host, role-assigned: manager/worker/apiserver/reverse-proxy) will own starting XCE components for its node's role, including starting/stopping the scheduler on a manager node in reaction to that node's controller reporting itself primary vs. standby over a local heartbeat (Unix domain socket, client logic shared via libxce). This supersedes this spec's core mechanism (controller-internal posix_spawn of its own scheduler via scheduler_proc.c/ha.c) though the underlying requirements this spec captured -- bug-1760's reactive-rejoin deadlock, wedge detection, graceful shutdown, controller-resilience invariants -- carry forward into xce-node-manager's requirements. This spec's approved design.md and its review findings (notably the fork()-vs-posix_spawn mutex-inheritance-deadlock analysis) remain a useful reference and are kept in place, not deleted. Do not implement this spec's tasks.md.",
|
|
"approvals": {
|
|
"requirements": {
|
|
"generated": true,
|
|
"approved": true
|
|
},
|
|
"design": {
|
|
"generated": true,
|
|
"approved": true,
|
|
"validation_note": "kiro-validate-design 2026-09-02: pass 1 found 1 critical issue -- Technology Stack's raw fork()+execve() justification for scheduler_proc.c incorrectly claimed no mutex-inheritance-deadlock risk because the call happens on a dedicated SlowLane worker thread; this doesn't hold, since the hazard comes from OTHER threads in the same multithreaded controller process holding a lock at fork time (glibc malloc, XCE mylock_t), directly re-triggering the risk class product.md's own locked decision (\"no fork() for snapshots\") already rejected. Fixed by switching to posix_spawn() throughout design.md (Technology Stack, both sequence diagrams, File Structure Plan, Components summary, architecture diagram, Error Handling) with the corrected reasoning stated explicitly. Pass 2 (fresh re-read + verified posix_spawn's argv/envp compatibility with execve, and confirmed via grep that the controller has zero existing SIGCHLD/signal handling to conflict with the new reaping logic) found no additional issues. GO."
|
|
},
|
|
"tasks": {
|
|
"generated": true,
|
|
"approved": false,
|
|
"validation_note": "kiro-spec-tasks 2026-09-02: 6 major tasks / 15 sub-tasks (plus 2 collapsed single-item major tasks) drafted covering all 25 requirement IDs (1.1-6.3) and every design.md component (SchedulerProcessManager, SchedulerConnectionBookkeeping, SchedOwnerWatch, the graceful-exit wire message). Independent task-graph sanity review (fresh subagent, pass 1): NEEDS_FIXES -- (1) task 1.2's (P) marker missing a _Boundary:_ tag, (2) task 2.4's _Depends:_ omitted 2.2 despite needing it, (3) Requirement 1.5's heartbeat-driven start-retry had no task wiring an actual periodic call site, (4) the old-rejoin-logic removal task was sequenced in Core, before ha.c wiring and tooling reconciliation, contradicting design.md's own Migration Strategy phase order (removal must be last), (5) design.md's own Testing Strategy lists a dedicated \"job survives scheduler killed mid-decision\" integration test with no owning task, (6) the tooling-reconciliation task covered only the known run-ha-soak.sh case, not design.md's broader \"flag any other dependent spec\" commitment. All 6 fixed: boundary tag added; dependency completed; new task 4.3 combines the heartbeat-driven start-retry and wedge-check wiring; the removal task became standalone Task 6 (last in the file, depending on 3, 4.1, 4.2, 5.7, 5.8, matching the Migration Strategy phases); new task 5.3 added for the job-durability scenario; task 5.8 broadened to sweep other specs/tooling. Sanity review pass 2 (fresh subagent): PASS -- all 6 fixes verified correct, plus fresh independent checks (full requirement-ID coverage, all _Depends:_ references resolve to real tasks including the two collapsed single-item major tasks, no (P)-marker boundary conflicts, Task 6's dependency list matches the Migration Strategy phases). Awaiting user approval before implementation."
|
|
}
|
|
},
|
|
"ready_for_implementation": false
|
|
}
|