fix(controller): fail loud on scheduler/worker disconnect instead of relying on the reply-wait timeout (bug-1693)
Violates this project's own recorded Decision Log entry: "No client reply-wait timeout as a fix for a hung request -- fail loud at the real transport/source instead of masking with a deadline backstop." OPCode_schedAdmin (cluster.c) and on_fetchfile (job.c, the worker proxy -- cluster.c's own comment says schedAdmin "mirrors on_fetchfile's proxy pattern", confirming one shared design mistake, not two independent bugs) both blocked on a multi-second pthread_cond_timedwait, replying "timeout" on expiry. handle_scheduler_leave()/handle_worker_leave() (the actual disconnect handlers) only nulled the endpoint pointer -- neither ever signaled the pending waiter, so a mid-wait disconnect was invisible until the deadline lapsed. The timeout was the ONLY failure-detection mechanism, exactly what the decision forbids. Both sites already had a working signal function on their success path (schedadmin_signal(), fetchfile_signal()) -- just never wired to the disconnect handlers. Fixed by calling them from handle_scheduler_leave()/handle_worker_leave() with a distinguishable -ECONNRESET outcome, so the waiter wakes immediately on disconnect instead of only on the deadline. Timeouts kept as defensive backstops for a genuinely wedged peer that never disconnects cleanly either -- this fix is about not relying SOLELY on the timeout, not removing it. schedadmin_signal_disconnect() must be called BEFORE handle_scheduler_leave() acquires c->sched.lock -- the dispatch wait holds that same lock for its entire duration, so signaling after acquiring it would deadlock. Found by an /xce-audit-invariants controller pass (Decision Log fidelity dimension). New test_fetchfile_disconnect.c plus extensions to test_sched_admin_dispatch.c/test_sched_worker_change.c; RED/GREEN independently verified against real elapsed-time assertions (pre-fix: 5001ms full-timeout wait; post-fix: <1s immediate wake). Full controller suite: 1181 tests, 2 failures -- both the pre-existing, unrelated bug-1561 overlayfs sandbox flake, confirmed via a clean meson-driven run. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AgYRU3zDTqNGV5Jk8aiKLg
This commit is contained in:
parent
c83b388be2
commit
3eba7c16bf
12 changed files with 1032 additions and 424 deletions
|
|
@ -775,6 +775,23 @@ int handle_worker_leave(cluster_t* c, int idx)
|
|||
|
||||
unlock(w);
|
||||
|
||||
/* bug-1693 (Decision Log: "No client reply-wait timeout as a fix for a
|
||||
* hung request -- fail loud at the real transport/source instead of
|
||||
* masking with a deadline backstop"). Wake any on_fetchfile() waiter
|
||||
* (job.c) proxied to this worker immediately instead of leaving it to
|
||||
* on_fetchfile's own 10s deadline -- mirrors handle_scheduler_leave's
|
||||
* identical schedadmin_signal_disconnect() fix in sched.c (same
|
||||
* Decision Log rule, same shared design mistake -- cluster.c's
|
||||
* OPCode_schedAdmin case comment already notes it "mirrors
|
||||
* on_fetchfile's proxy pattern"). Deliberately called AFTER releasing
|
||||
* w's lock: fetchfile_signal_worker_disconnect() only takes
|
||||
* g_fetchfile_mu (job.c, file-local) + each matched waiter's own mu,
|
||||
* never any worker_t lock, so there is no ordering dependency, and `w`
|
||||
* remains a valid pointer for the comparison (this function's vget'd
|
||||
* reference is still held). A no-op if no fetchfile request happens to
|
||||
* be pending against this worker. */
|
||||
fetchfile_signal_worker_disconnect(w);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue