Rongsong Shen
7b3dfed56e
dispatch_a_job_() (tasks 3.1-3.3) now owns notification entirely for every outcome -- notify_dispatch() on a retryable failure, mark_job_fail()'s own hook chain on a terminal failure, nothing on success. handle_jobdispatch()'s loop still unconditionally called notify_dispatch() itself for every job regardless, producing two conflicting outcome reports for any failed dispatch. Removed that caller-side call; the loop is now a thin dispatch-and-free loop with no notification logic of its own. New test_jobdispatch_no_double_notify.c drives a 3-job batch (success, retryable, terminal) through handle_jobdispatch() and confirms exactly one notification fires (from the retryable job only), not four. Independently reviewed and approved. Confirmed handle_jobdispatch()'s sole caller never depended on its notification behavior (always returns 0 unconditionally). Flagged that test_commit_barrier_reply.c's test_jobdispatch_receipt_ack_no_wal_append is now stale for a second, independent reason (notify count, not just WAL count) -- both left for task 5.4 per Requirement 5.3. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cxa1PmqAB5PyXfJaNvj8TN |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||