[mgravell]

ExecuteSyncImpl stopped waiting as soon as it observed IResultBox.IsFaulted:

result = TryPushMessageToBridgeSync(message, processor, source, ref server);
if (!source.IsFaulted) // if we faulted while writing, we don't need to wait
{
    ...
    if (Monitor.Wait(source, TimeoutMilliseconds)) ...
}
...
var val = source.GetResult(out var ex, canRecycle: true);

That's only safe for the case the comment describes — the message faulting inline on this thread during the write, where the completion's PulseAll ran under our own (reentrant) lock with no waiter and is already gone. IsFaulted can't distinguish that from a fault published by another thread, and those two are not the same:

• ResultProcessor.SetException publishes the exception with no lock (a plain volatile write);
• the matching pulse only follows later, from Message.Complete → ActivateContinuations, which needs lock(box) — held by the caller.

The message is on the wire from inside TryPushMessageToBridgeSync (WriteMessageTakingWriteLockSync flushes, then still has SetIdle, UnmarkActiveMessage and _singleWriter.Release() to do). So a caller preempted anywhere between the flush and the IsFaulted read sees the fault, skips the wait, exits the lock, and recycles the box into the [ThreadStatic] pool — while the reader thread is still on its way to PulseAll on that very object.

The next synchronous call on that thread then borrows the same box, parks in Monitor.Wait, and is woken by that stale pulse. It returns with neither result nor exception. Its real reply lands on the already-recycled box, so every later reply on that thread is shifted by one — and because the pool is thread-static, the damage survives new multiplexers and new servers.

Fix

Track completion explicitly rather than inferring it:

• ActivateContinuations sets _completed inside the lock, immediately before the pulse.
• The sync waiter's early-out tests IsCompleted, not IsFaulted — the inline-fault case still short-circuits (it completed under our own lock), and a fault from another thread now correctly waits for the pulse it is owed.
• The wait is a loop on IsCompleted, so a pulse the waiter did not cause can no longer shorten it; the original deadline is preserved across such wakes so the timeout budget is unchanged.
• Recycling clears the flag; since the box is only recycled once IsCompleted, no other thread can still be touching it.

Every path that faults a sync box does subsequently reach Message.Complete (SetExceptionAndComplete, or ComputeResult returning true, or Fail(...) followed by Complete(...) in HandleWriteException), so there is no path that now waits where it previously returned.

How it was found / verified

Reported against Garnet CI as microsoft/garnet#2110, where it surfaced as LuaScriptTests.Issue1079 losing its exception and Issue1235 later receiving it, with counts matching 1:1 — the thread-static box is the only thing in the client that carries result state across multiplexers and servers, which is what pins the diagnosis.

Reproduced end-to-end against the in-process test server. On this machine the window is too narrow to hit naturally (20k iterations, no hit, even pinned to 2 cores under load), but with a temporary 2ms sleep injected between the push and the IsFaulted read — standing in for the preemption a loaded 2-core CI runner supplies for free — it reproduces in single-digit iterations, both symptoms:

• a PING returning null with no exception, and
• a PING throwing the previous command's RedisServerException.

With this change the same harness is clean over repeated runs. The probe was removed before commit; the tests left behind (ResultBoxCompletionTests) pin the contract deterministically without it: a fault alone is not completion, a stray pulse does not end the wait, and recycling resets the state.

Full suite green against the docker topology on net10.0 (5941 passed) and net8.0 (5875 passed), Build.csproj -c Release clean with 0 warnings.