I'm reviewing changes to a widely used library, which are supposed to be refactoring, and so we want to minimize the risk of introducing any accidental regression. Of course, there are changes from this:

    if (!BlobExists()) 

to this:

    if (!await BlobExists(cancellationToken))

This looks like an impure refactoring - even ignoring the CancellationToken parameter, the return type of BlobExists must have changed to Task<bool>. So, whether the code blocks the thread while the blob existence is checked on some other thread has changed. But, I also know in normal usage the intent of the code is probably the same, and in most cases we are unlikely to depend on the thread-blocking sync-waiting-on-async-result behavior.

That is, at least we are unlikely to know that we intended to depend on the thread-blocking sync-over-async behavior. What are the risk scenarios here, where we might unknowingly actually be depending on that behavior, or in general, unpleasantly surprised to find we've introduced a bug?

I'm reviewing changes to a widely used library, which are supposed to be refactorings, and so we want to minimize the risk of introducing any accidental regression. Of course, there are changes from this:

    if (!BlobExists()) 

to this:

    if (!await BlobExists(cancellationToken))

This looks like an impure refactoring - even ignoring the CancellationToken parameter, the return type of BlobExists must have changed to Task<bool>. So, whether the code blocks the thread while the blob existence is checked on some other thread has changed. But, I also know in normal usage the intent of the code is probably the same, and in most cases we are unlikely to depend on the thread-blocking sync-waiting-on-async-result behavior.

That is, at least we are unlikely to know that we intended to depend on the thread-blocking sync-over-async behavior. What are the risk scenarios here, where we might unknowingly actually be depending on that behavior, or in general, unpleasantly surprised to find we've introduced a bug?

I'm reviewing changes to a widely used library, which are supposed to be refactoring, and so we want to minimize the risk of introducing any accidental regression. Of course, there are changes from this:

    if (!BlobExists()) 

to this:

    if (!await BlobExists(cancellationToken))

This looks like an impure refactoring - even ignoring the CancellationToken parameter, the return type of BlobExists must have changed to Task<bool>. So, whether the code blocks the thread while the blob existence is checked on some other thread has changed. But, I also know in normal usage the intent of the code is probably the same, and in most cases we are unlikely to depend on the thread-blocking sync-waiting-on-async-result behavior.

That is, at least we are unlikely to know that we intended to depend on the thread-blocking sync-over-async behavior. What are the risk scenarios here, where we might unknowingly actually be depending on that behavior?

I'm reviewing changes to a widely used library, which are supposed to be refactoring, and so we want to minimize the risk of introducing any accidental regression. Of course, there are changes from this:

    if (!BlobExists()) 

to this:

    if (!await BlobExists(cancellationToken))

This looks like an impure refactoring - even ignoring the CancellationToken parameter, the return type of BlobExists must have changed to Task<bool>. So, whether the code blocks the thread while the blob existence is checked on some other thread has changed. But, I also know in normal usage the intent of the code is probably the same, and in most cases we are unlikely to depend on the thread-blocking sync-waiting-on-async-result behavior.

That is, at least we are unlikely to know that we intended to depend on the thread-blocking sync-over-async behavior. What are the risk scenarios here, where we might unknowingly actually be depending on that behavior, or in general, unpleasantly surprised to find we've introduced a bug?