Waiting for cancelled async method from UI thread?

I have a WPF program appending to a textbox asynchronously.
If the user selects a new provider via combobox, the appending should be cancelled and called again with the new provider. problem is the updateMoviesTask?.Wait() deadlocks.
I guess it is because UpdateMovies() waits for ui thread and ProviderId property waits for the task. How can I solve this?

CancellationTokenSource source;
Task updateMoviesTask;

async Task UpdateMovies()
{
    source?.Dispose();
    source = new CancellationTokenSource();

    CancellationToken cancel = source.Token;

    var request = new GetPopularRequest(Country.Germany);

    for (int i = 1; i <= TotalPages; i++)
    {
        request.Page = i;
        request.ProviderId = providerId;

        var getPopularResponse = await justWatchClient.GetPopularAsync(request);

        // do ui stuff here        

        if (cancel.IsCancellationRequested)
            return;
    }
}

public GetProviderResponse ProviderId
{
    get { return providerId; }
    set
    {
        this.providerId = value; 
        this.source?.Cancel();
        updateMoviesTask?.Wait();
        updateMoviesTask = this.UpdateMovies();
        this.OnPropertyChanged("");
    }
}

If I understand correctly, then you need to - Look at this version of the code (without taking into account the handling of possible exceptions):

    private CancellationTokenSource source = new();
    private readonly object locker = new();

    private void UpdateMovies() => Task.Run(() =>
    {
        source.Dispose();
        source = new CancellationTokenSource();
        CancellationToken cancel = source.Token;

        lock (locker)
        {
            var request = new GetPopularRequest(Country.Germany);

            for (int i = 1; i <= TotalPages; i++)
            {
                request.Page = i;
                request.ProviderId = providerId;

                // Need a synchronous version of the method
                // var getPopularResponse = await justWatchClient.GetPopularAsync(request);
                var getPopularResponse = justWatchClient.GetPopular(request);

                // do ui stuff here        

                if (cancel.IsCancellationRequested)
                    return;
            }
        }
    });

    public GetProviderResponse ProviderId
    {
        get { return providerId; }
        set
        {
            this.providerId = value;
            UpdateMovies();
            this.OnPropertyChanged(string.Empty);
        }
    }

It looks like your flow is as follows: user modifies the ProviderId property. The property then cancels any running UpdatMovies operations and start a new.

Good UX would require the user to start such long running operations explicitly. Selecting an value from an innocent ComboBox shouldn't result in a resource intensive surprise. Instead let the user configure the opeartion (e.g. select the ProviderId and start it by clicking in a e.g. "Update" button. Now everything is transparent to the user. You could even allow the user to decide whether he wants to wait for completion or to abort the running operation.

<Window>
  <StackPanel>
    <CombBox SelectedItem={Binding ProviderId}" />
    <Button Content="Start update"
            Command="{Binding UpdateMoviesCommand}" />
  </StackPanel>
</Window>

See Microsoft Docs: Relaying Command Logic for the RelayCommand implementation used in the example.

public object ProviderId { get; set; }
public ICommand UpdateMoviesCommand => new RelayCommand(ExecuteUpdateMoviesCommand, CanExecuteUpdateMoviesCommand);
private CancellationTokenSource CancellationTokenSource { get; set; }  
  = new CancellationTokenSource();
private SemaphoreSlim Semaphore { get; }
  = new SemaphoreSlim(1, 1);

private bool CanExecuteUpdateMoviesCommand(object commandParameter)
  => this.ProviderId is not null;

private async void ExecuteUpdateMoviesCommand(object commandParameter)
{
  this.CancellationTokenSource.Cancel();

  // Asynchronously wait until UpdateMoviesAsync has returned 
  // and the finally block was executed to allow the current context to continue.
  await this.Semaphore.WaitAsnyc();
  
  try
  {  
    await UpdateMoviesAsync(this.CancellationTokenSource.Token);
  }
  catch (OperationCanceledException)
  {
  }   
  finally 
  {    
    this.CancellationTokenSource.Dispose();
    this.CancellationTokenSource = new CancellationTokenSource();

    // Allow the waiting context to call UpdateMoviesAsync
    this.Semaphore.Release();
  }
}

private async Task UpdateMoviesAsync(CancellationToken cancellationToken)
{
  var request = new GetPopularRequest(Country.Germany);

  for (int i = 1; i <= TotalPages; i++)
  {
    request.Page = i;
    request.ProviderId = providerId;

    // Consider to make justWatchClient.GetPopularAsync 
    // cancellable too to improve performance
    var getPopularResponse = await justWatchClient.GetPopularAsync(request);

    // do ui stuff here        

    cancellationToken.ThrowIfCancellationRequested();
  }
}

Alternatively, use the ComboBox.SelectionChanged event to trigger the async operation.

> If the user selects a new provider via combobox, the appending should be cancelled and called again with the new provider. problem is the updateMoviesTask?.Wait() deadlocks. I guess it is because UpdateMovies() waits for ui thread and ProviderId property waits for the task. How can I solve this?

Yes, that's a classic deadlock I describe on my blog.

With these kinds of "replace the operation updating the UI" problems, I generally prefer a token-based approach. Every operation is handed a token, and only updates the UI if its token matches the current token. Then, when starting a new operation, regenerate the token before passing it to the new operation.

In old-school code, I've just used something as simple as object as the token, but these days a CancellationToken is just as good. And, in fact, your code already has one; it just has to observe it anytime before it updates the UI.

Side note: sometimes you have to wait for the previous operation to complete, e.g., if it's updating some external resource like a database or cache and you don't want it interfering with the current operation. But if the operations only do some queries and update the UI, then waiting for the previous operation to complete is not necessary; you can just regenerate the token and start the replacement operation immediately.

CancellationTokenSource source;

async Task UpdateMoviesAsync(CancellationToken cancel)
{
  var request = new GetPopularRequest(Country.Germany);

  for (int i = 1; i <= TotalPages; i++)
  {
    request.Page = i;
    request.ProviderId = providerId;

    var getPopularResponse = await justWatchClient.GetPopularAsync(request);

    if (cancel.IsCancellationRequested)
      return;

    // do ui stuff here
  }
}

public GetProviderResponse ProviderId
{
  get { return providerId; }
  set
  {
    providerId = value; 
    source?.Cancel();
    source?.Dispose();
    source = new CancellationTokenSource();
    _ = this.UpdateMoviesAsync(source.Token); // see note below
    this.OnPropertyChanged("");
  }
}

Discarding the task _ = ... is problematic. It's actually ignoring any errors that can come from UpdateMoviesAsync. And making UpdateMoviesAsync async void instead of async Task would be even worse - you'd crash on errors. You'll want to handle this better than either of these approaches. My recommended pattern is the "notify task" pattern, which takes a Task and makes it observable (including exceptions). The Notify Task pattern is described in this article of mine. Note that these days most MVVM libraries have some kind of NotifyTask<T> built-in, though it sometimes goes by different names.