---
id: "bug-1864"
status: "fixed"
status_updated: "2026-09-25"
status_note: "0d3bb965"
component: "lib"
severity: "unknown"
timestamp: "2026-09-25T14:26:45Z"
last_seen: "2026-09-25T14:26:45Z"
occurrences: 1
files: ["src/lib/vtaskmgr.c", "src/lib/dataq.c", "src/lib/netio.c"]
tags: ["lib", "vtaskmgr", "ordering", "race", "replication", "ha", "controller"]
related: []
fix_commits: ["0d3bb965"]
legacy: true
gitea_issue: 283
gitea_synced_status: "fixed"
gitea_synced_hash: "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