Skip to content

test(zookeeper): close-start assertion races after the native-read completion barrier #11346

Description

@ReubenBond

Observed failure

ZooKeeperReadRetryTests.ReadOwner_CanceledCaller_JoinsNativeTasksBeforeClose failed in the ZooKeeper provider net8.0 Debug CI lane with Assert.False() at line 319: closeStarted.Task.IsCompleted was already true.

Assert.False() Failure
Expected: False
Actual:   True
at ZooKeeperReadRetryTests.ReadOwner_CanceledCaller_JoinsNativeTasksBeforeClose():line 319

Ordering to investigate

The test first verifies that owner completion and close are pending while the native request is blocked. It then releases the request and awaits an AfterRequest signal:

first.SetResult();
await firstCompleted.Task.WaitAsync(TestContext.Current.CancellationToken);
Assert.False(owner.Completion.IsCompleted);
Assert.False(closeStarted.Task.IsCompleted); // line 319
await closeStarted.Task.WaitAsync(TestContext.Current.CancellationToken);
Assert.False(owner.Completion.IsCompleted);

The AfterRequest signal reports progress; it does not hold the owner's continuation after the native request completes. The owner can begin close before the test resumes at line 319. The separate releaseClose gate still holds owner completion pending, so the observed close-start does not by itself demonstrate a failure to join the native request or await close.

Make the assertion match the intended phase ordering, or add an explicit barrier if the intermediate state itself must be inspected. Preserve the earlier pre-release checks, caller cancellation-token identity, absence of a second read, and owner completion waiting for close.

Scope and existing fixes

The failing test blob is identical in the actual tested merge and main 8bc9fd2 (c48c978f5c092e8ee02e4da08b9fb52e828334d9). This is outside the Durable Messaging changes. Checkout evidence matters here: the failure is keyed to the PR head, but CI compiled its merge with main.

The related resilience PR #11338 (2dace6e9f25d44c255a5e5a9805ea72b52b9f5f6) was already included in that tested merge, so adopting main would not newly apply it. Exact test-name, ReadOwner, canceled-caller and closeStarted issue/PR searches found no matching tracker or newer fix. No manual workflow rerun or assertion workaround was used to replace the failing evidence.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions