The most recent documentation forTask‘s explicit interface member implementation of IAsyncResult.CompletedSynchronously states the following:

true if the operation completed synchronously; otherwise, false.

According to this 2015 blogpost by Stephen Cleary and this stackoverflow answer from 2016, the property always returns false.

This is still the case in 2024 if we look at the source code which doesn’t provide any further clarification as to why:

/// <summary>
/// Gets an indication of whether the asynchronous operation completed synchronously.
/// </summary>
/// <value>true if the asynchronous operation completed synchronously; otherwise, false.</value>
bool IAsyncResult.CompletedSynchronously => false;

The Task API infrastructure allows for a synchronous execution for example via:

• Task.RunSynchronously
• TaskContinuationOptions.ExecuteSynchronously

It is true that for all of this the TaskScheduler is involved, but for the synchronous execution I could find in the code it is almost exclusively done through calls to

protected abstract bool TryExecuteTaskInline (System.Threading.Tasks.Task task, bool taskWasPreviouslyQueued);

which returns according to the documentation

A Boolean value indicating whether the task was executed inline.

The documentation suggests that custom TaskScheduler implementers call the base TaskScheduler.TryExecuteTask which has access to the internal bool Task.ExecuteEntry()

Now at this point, we can’t really pass the information to the task object that the task scheduler decided that it can run it synchronously instead of scheduling it.

But Microsoft could have introduced overloads to both base TaskScheduler.TryExecuteTask and internal Task.ExecuteEntry() accepting a bool runsInline which could be used to set internal flags upon successful completion that IAsyncResult.CompletedSynchronously could make use of. Or better yet they could have made those the only options from the beginning so to prevent custom task schedulers implementations from messing up by calling the wrong overload.

So, I am left to wonder:

1. Was it a non-priority/oversight at the time which locked the API in such a manner that it couldn’t really be reliably introduced later on via the overloads
2. Was it a well-thought out design decision that a certain Task object won’t be able to always determine reliably if completed synchronously or not. If so is there a link to (semi-)official rationalization of this because the official documentation is still silent/misleading about it.

If you know why it won’t be feasible and provide some clear examples demonstrating it I will accept the answer in the event that no official link/position surfaces in another answer.