myxce/.wolf/bugs/bug-1864.md
Rongsong Shen 25d8a461fa
chore: gitea-sync refreshes 23 recent bug issues to the record format
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-28 03:44:30 +00:00

3.1 KiB

id status status_updated status_note component severity timestamp last_seen occurrences files tags related fix_commits legacy gitea_issue gitea_synced_status gitea_synced_hash
bug-1864 fixed 2026-09-25 0d3bb965 lib unknown 2026-09-25T14:26:45Z 2026-09-25T14:26:45Z 1
src/lib/vtaskmgr.c
src/lib/dataq.c
src/lib/netio.c
lib
vtaskmgr
ordering
race
replication
ha
controller
0d3bb965
true 283 fixed 4f0a10cfc116

bug-1864: Standby controllers NACK in-order WAL catch-up entries (ae_reject_logmismatch, prevIdx one ahead…

Description

Standby controllers NACK in-order WAL catch-up entries (ae_reject_logmismatch, prevIdx one ahead of their log) ~576 times in a 45-min run (data/logs, 2026-09-25): e.g. ctrl-2 21:37:50.115 handled walCatchupEntry seq 258 (prevIdx=149) BEFORE seq 257 (prevIdx=148). With both standbys NACKing, the primary marks them catch-up, loses its write quorum and answers jobdispatch/join with E_XCE_NOT_READY (-10013) (ctrl-1 21:39:24.494); the scheduler client fails over (bug-1850), rejoins, and gets a JOBS_PUSH built from lagging committed state -> 'refusing resync state 0x1 ... existing job is RUN' WARNs for 14 jobs.

Environment

Not recorded (migrated from buglog.json).

Reproduction

Not recorded (migrated from buglog.json).

Root cause

vtaskmgr's dispatcher (pick_eligible_task -> dataq_deq(taskq, vtask_eligible)) evaluates each queued task's eligibility one item at a time while holding only the taskq lock; the per-endpoint busy flag it reads (endpoint_is_task_blocked) is cleared by the vcpu finishing the previous message WITHOUT that lock. Within one scan, task N (seq 257) is checked while the endpoint is still busy and skipped, the endpoint unblocks, and task N+1 (seq 258) for the SAME endpoint is then found eligible and dequeued first. endpoint_block_tasks gives mutual exclusion per endpoint but not FIFO order. Log proof (ctrl-2 21:37:50.113-.118): '04b650 not eligible' -> 'endpoint not blocked' -> '03cae0 eligible' in one scan; 03cae0=seq 258, 04b650=seq 257; tasks enqueued in arrival order by the single netio thread (vtask_handle_msg).

Fix

UPDATE (2026-09-25): Fix (uncommitted): dataq gains dataq_deq_ctx (per-scan matcher context); vtaskmgr's scan is now vtask_deq_eligible(taskq, is_blocked) with a per-scan set of endpoints found busy -- every later task of such an endpoint stays ineligible for the rest of that scan (overflow past 64 distinct busy endpoints makes all later IO tasks ineligible), so per-endpoint FIFO holds without taking any new lock (bug-1282 ABBA). Test lib/testsuite/test_vtask_order.c: is_blocked injected to flip ep busy->free mid-scan; reproduced the reorder (N+1 dequeued) before, NULL after; other-endpoint progress and FIFO/generic cases pass. Suites: lib 1/1, controller 5/5, worker 10/10, scheduler 87/87, harness 5/5. Reorder signature (reject prevIdx=K then accept K-1): user run 26 (-> 576 NACKs incl. cascades), pre-fix chaotic soaks 2 and 5.

Verification

Not recorded (migrated from buglog.json).

References

  • Gitea: #283