Cancellation

Every method that sends a request has an Async form that takes a CancellationToken: client operations such as client.Users.FindAsync, object methods such as user.UpdateAsync and SaveAsync, the list methods LoadNextPageAsync, AllAsync, ListAutoPagingAsync and ListAutoPaging(cancellationToken), and the file transfers client.RemoteFiles.UploadFileAsync and DownloadFileAsync, and the uploads of client.Transfers, described in File Transfers.

Cancelling the token stops the operation wherever it is: waiting for a response, waiting to retry, reading or writing file contents, or between pages and upload parts. The operation then ends with an OperationCanceledException (or a TaskCanceledException, which derives from it), and it starts no further request, retry, page or part.

Methods without a token, including User.Find and LoadNextPage, do not support token-based cancellation.

Disposing the client also cancels its running operations.

Example Request

using FilesCom;
using FilesCom.Models;

using (var cancellation = new CancellationTokenSource(TimeSpan.FromMinutes(10)))
{
    try
    {
        await client.RemoteFiles.UploadFileAsync(localPath, destinationPath, cancellationToken: cancellation.Token);
    }
    catch (OperationCanceledException)
    {
        Console.WriteLine("The upload was cancelled.");
    }
}

What Cancellation Leaves Behind

Cancellation stops the SDK operation. It does not undo requests Files.com has already received. If the last request of an upload was sent before you cancelled, the file may still be completed.

The SDK passes the token to the streams you give it. A stream that ignores its token finishes its current read or write before the operation stops.

  • UploadFileAsync(destinationPath, stream, ...) disposes the stream when it ends, including when it is cancelled.
  • DownloadFileAsync(path, stream) leaves your stream open.
  • DownloadFileAsync(path, localPath) closes the local file when it ends. After a failure or cancellation, the file may be partly written.

Timeouts

The ReadTimeout and WriteTimeout settings end a request whose connection stalls: one that waits too long for its response or for more of it, or an upload part that cannot send. It then fails with NetworkTimeoutException, not OperationCanceledException, after the retries a connection failure gets. An error response whose body stops arriving fails with its HTTP status instead, as an InvalidResponseException. They do not limit a transfer that keeps moving, however long it takes. To limit a whole operation, use a token that cancels itself, as in the example.