PullAsync returns IsSuccessful = false even though FailedRequests shows success (200 OK)

[taddisateesh]

Description:

When calling PullAsync on a table using CommunityToolkit.Datasync.Client, the PullResult.IsSuccessful flag is returning false. However, drilling into PullResult.FailedRequests reveals that the request was actually successful:

StatusCode = 200

ReasonPhrase = "OK"

IsSuccessful = true inside the ServiceResponse

This creates confusion because the pull operation is flagged as failed (IsSuccessful = false) even though the server-side request succeeded.

Steps to Reproduce:

Call PullAsync on a DbContext table:

var pullResult = await dbContext.Set().PullAsync(token);

Check the result:

pullResult.IsSuccessful is false

pullResult.FailedRequests.Count is 1

But the failed request shows StatusCode = 200

Expected Behavior:

If the server returns 200 OK and the request is marked successful, then PullResult.IsSuccessful should also be true.

Failed requests should only be recorded when there’s an actual error (e.g., 4xx/5xx status codes, conflicts, or network errors).

Actual Behavior:

PullResult.IsSuccessful = false

FailedRequests contains a request with 200 OK and IsSuccessful = true

No clear root cause is provided in the exception or logs.

Impact:

It’s currently impossible to determine the real root cause of the failure.

App logic may incorrectly treat successful pulls as failed.

This blocks proper error handling, especially for conflict resolution.

What platforms?

• Client:
  • What platform (Android, iOS, Windows, etc.) versions are you running on?
  • iOS and Android
  • Does it happen in an emulator / simulator, or only on a real device?
  • Both
  • Version of dotnet being used to compile?
  • 9.0
  • .NET Runtime Environment (WPF, UWP, WinUI3, MAUI, etc.):
  • MAUI
  • Datsync Toolkit NuGet versions?
  • 9.0.5
  • GitHub repository containing the code (optional, but helps!)

Screenshots

[adrianhall]

I’m about six weeks away from being able to look at this. Can you possibly get a full trace of the network activity that causes this? Alternatively, an x unit test case that shows off the error is required.

We already have tests that are multi-request showing a full cycle, so I need to understand what is different about your version.