[BUG] Blob Storage's downloadToFile deletes files after toFuture is called

[hongee]

Describe the bug
After calling downloadToFile (with or without overwrite = true), the operation succeeds, and the file, for a brief moment, is successfully downloaded and persisted on disk. However, if a toFuture subscriber is attached and then subsequently converted to a Scala Future (using either Scala's built in compat, or via Reactor's Scala extensions), a cancel signal is fired, and the handler here fires and deletes the file:

azure-sdk-for-java/sdk/storage/azure-storage-blob/src/main/java/com/azure/storage/blob/specialized/BlobAsyncClientBase.java

Line 1039 in b59f999

Files.deleteIfExists(Paths.get(filePath));

edit - quick update - Mono's toFuture does indeed fire off a cancel: https://github.com/reactor/reactor-core/blob/c6b75f2578ee5f201ac06add2239322cc5b7bfcd/reactor-core/src/main/java/reactor/core/publisher/MonoToCompletableFuture.java#L59, which makes the downloadToFile methods impossible to use if a CompletableFuture is desired. May I suggest loosening the check for deletion? 😄

I'm not very familiar with Reactor, and would be happy to find out if I'm doing something wrong, or if there's a workaround. We are on a Scala codebase that relies heavily on Futures, so not using a Future is not quite an option.

Exception or Stack Trace
N/A

To Reproduce
Steps to reproduce the behavior:
See the following snippet

Code Snippet

blobContainerClient
  .getBlobAsyncClient(myBlobKey)
  .downloadToFile("my/path")
  .onComplete { ...file is fine here... }
  .doFinally { ... eventually `cancel` is fired instead of `complete` ... }
  .toFuture.asScala.map { ... file disappears ... }

Expected behavior
Don't delete my file :(

Screenshots
N/A

Setup (please complete the following information):

• OS: macOS Catalina
• IDE : Intellij Ultimate
• Version of the Library used: 12.4.0

Additional context
Could be related to spring-projects/spring-framework#22952, even though this appears to be fixed?

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Bug Description Added
• Repro Steps Added
• Setup information Added

[rickle-msft]

@hongee Thank you for reporting this, and sorry for the delay! I am just now noticing we haven't responded.

We do need to delete files in the case of cancellation because we don't want to leave unwanted/incomplete/corrupted files hanging around on the disk. So our best path forward is to try to understand why Reactor has this behavior when being converted to a Future. @anuchandy, do you have any insight into why Reactor would be doing this? Or if perhaps there is another safe way of cleaning up resources that would permit customers to use Futures more readily?

[hongee]

Thanks for looking into this! :) Yeah it doesn't seem like wrong behavior - just not sure why toFuture sends a close signal after complete, and why those aren't mutually exclusive. Not familiar enough to say how possible this is, but perhaps a flag can be set if the completion signal is received, and a close coming after complete could be ignored?

Currently we're using a hacky workaround where we pass a symlink of the desired path to the method so at least we don't lose the downloaded file :)

[rickle-msft]

That's a good suggestion. I can investigate that a bit along with trying to understand Reactor's behavior a bit better.

[anuchandy]

@rickle-msft - I've opened an issue/question reactor/reactor-core#2070 to understand more about this behavior.

[anuchandy]

The issue is fixed in the reactor-core.

[Petermarcu]

Can this issue be closed?

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.