#499: terminate coordinator loop on disposed data source / wrapped cancellation

[jeremydmiller]

Fixes #499.

Problem

ProjectionCoordinatorBase.executeAsync's per-set error handler treated any exception from TryAttainLockAsync as a transient "will retry later" and looped again after Task.Delay. During host shutdown, a TryAttainLockAsync that faults because the underlying NpgsqlDataSource is being disposed got re-polled instead of terminating — amplifying one racing OpenAsync into the burst of ObjectDisposedException: 'Npgsql.PoolingDataSource' aborts measured in marten#4874. This is priority 2 (case B) of that issue — the root-cause drain correctness fix (the priority-1 symptom guard lives in weasel#349).

Change

In the inner lock-attempt catch of ProjectionCoordinatorBase.executeAsync:

• ObjectDisposedException is now terminal — the data source is gone for good, so the loop returns instead of re-polling a dead pool.
• Check stoppingToken.IsCancellationRequested before the retry Task.Delay — a cancellation that surfaces wrapped (not a bare OperationCanceledException) now terminates the loop the same way the outer catch already does, rather than being logged as a lock error and re-polled.

Tests

Two regression tests in ProjectionCoordinatorBaseTests, both confirmed to fail against the pre-fix loop:

• terminates_the_loop_when_the_data_source_is_disposed_mid_lock_attempt — a disposed-pool fault stops the loop after exactly one attempt (a re-polling loop would keep incrementing the attempt counter).
• terminates_on_a_wrapped_cancellation_during_a_lock_attempt_without_logging_a_lock_error — an in-flight attempt whose cancellation surfaces wrapped terminates without logging a "will retry later" lock error (asserted via a capturing logger).

All 13 coordinator tests pass with the fix.

🤖 Generated with Claude Code