[TimelordUK]

Follow-up to #495. After that merge, cancel/again-after-confirm-at-100 failed once more on Linux CI (run):

  action cancel
  cancel-cb ok
  action cancel again
+ error HY008 0 Operation canceled more=false
  cancel-cb error cannot cancel query (cancel already requested) id 0
- error HY008 0 Operation canceled more=false

Cause

#495 held native results until the accepted cancel's callback had run, but not for the refusal of a repeated cancel. The sequence that slipped through:

1. The first cancel's callback runs.
2. Inside it, the scenario cancels again. The refusal is scheduled with setImmediate, so it runs in the next loop iteration's check phase.
3. The first cancel settles. Nothing is held yet.
4. The fetch's HY008 completion lands in the poll phase, before that check phase. Nothing is pending any more, so it runs straight away, ahead of the refusal.

Fix

The notifier now counts every cancel callback still to run, accepted or refused (holdForCancel). It releases what is waiting one tick after the count gets back to 0.

Test

test/cancel-order.test.js uses a stub connection and needs no server. Its first case reproduces the CI interleaving deterministically: a process.nextTick registered from the cancel callback runs after that callback but before the refusal's setImmediate.

• On master's notifier, that case fails.
• With this change, all 5 cases pass.

Local runs (WSL, SQL Server 2022): contract, replay, cancel-order, cancel-regression, querycancel and cancel-stress, 386 passing.

🤖 Generated with Claude Code