Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BT-724 Fix BlobPathBuilder failing on retrieving existing filesystem #6816

Merged
merged 6 commits into from
Aug 5, 2022
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ import cromwell.filesystems.blob.BlobPathBuilder._

import java.net.MalformedURLException
import java.net.URI
import java.nio.file.FileSystemNotFoundException
import java.nio.file.FileSystems
import scala.jdk.CollectionConverters._
import scala.language.postfixOps
Expand Down Expand Up @@ -68,9 +69,16 @@ class BlobPathBuilder(credential: AzureSasCredential, container: String, endpoin
validateBlobPath(string, container, endpoint) match {
case ValidBlobPath(path) =>
Try {
val fileSystem = FileSystems.newFileSystem(new URI("azb://?endpoint=" + endpoint), fileSystemConfig.asJava)
val blobStoragePath = fileSystem.getPath(path)
BlobPath(blobStoragePath, endpoint, container)
val fileSystem = Try {
FileSystems.getFileSystem(new URI("azb://?endpoint=" + endpoint))
} recover {
// If no filesystem already exists, this will create a new connection, with the provided configs
case _: FileSystemNotFoundException => FileSystems.newFileSystem(new URI("azb://?endpoint=" + endpoint), fileSystemConfig.asJava)
}

val blobStoragePath = fileSystem.map(_.getPath(path))
// If there is a remaining issue reaching the filesystem, this will rethrow the exception
blobStoragePath.map(BlobPath(_, endpoint, container)).get
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally in Scala we don't want unprotected .get calls resulting in exceptions, even when we expect and properly handle those exceptions. This is partially style and partially performance - my understanding is that throwing exceptions up and down deep stacks is very expensive, so it's good to get out of the habit.

I think there's a different way to structure this whole block so it returns the InvalidFilePath objects directly rather than throwing and creating them in recovery, we can maybe workshop it tomorrow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback here, I figured this wasn't a great way to go, but more generally I wasn't able to find great advice on handling nested try situations overall. I realized now looking at it again, I think the nested try is totally unnecessary 😅 Sounds good!

}
case UnparsableBlobPath(errorMessage: Throwable) => Failure(errorMessage)
}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -62,4 +62,15 @@ class BlobPathBuilderSpec extends AnyFlatSpec with Matchers{
val fileText = (is.readAllBytes.map(_.toChar)).mkString
fileText should include ("This is my test file!!!! Did it work?")
}

ignore should "build duplicate blob paths in the same filesystem" in {
val endpoint = BlobPathBuilderSpec.buildEndpoint("coaexternalstorage")
val store = "inputs"
val evalPath = "/test/inputFile.txt"
val sas = "{SAS TOKEN HERE}"
val testString = endpoint + "/" + store + evalPath
val blobPath1: BlobPath = new BlobPathBuilder(new AzureSasCredential(sas), store, endpoint) build testString getOrElse fail()
val blobPath2: BlobPath = new BlobPathBuilder(new AzureSasCredential(sas), store, endpoint) build testString getOrElse fail()
blobPath1 should equal(blobPath2)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is a good demonstration but I don't know that we actually want to check it in. This is a good topic to discuss in Michael's meeting next week, how should we be handling automated tests for this stuff?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed here, I've been leaving this for the time being because I have been using it to verify I haven't broken these changes, but I can remove this before merge

}