Normal stream errors unexpectedly kill the fiber in multipartUpload

[chriskite]

The signature for multipartUpload is:

def multipartUpload[R](
  bucketName: String,
  key: String,
  content: ZStream[R, Throwable, Byte],
  options: MultipartUploadOptions
)(parallelism: Int): ZIO[R, S3Exception, Unit] =

content, the stream passed in by the library user, has the error channel type Throwable, indicating that it is allowed to fail with a Throwable.

However, multipartUpload does the following:

.refineOrDie {
  case e: S3Exception => e
}

Now the Throwable we were allowed to fail with causes an unexpected fiber death. This caused a production issue for us, as without looking into the code we would not have known that something allowed in the method signature would be considered a fiber-killing code defect.

This behavior was introduced in #170 and I would argue it is incorrect. A stream failing with a normal error is not a defect that cannot be recovered from. I would suggest that instead of dying or wrapping content stream errors with a custom type, just keep the Throwable type as the return error channel type for multipartUpload.

I would be happy to put together a PR for this change.

[regis-leray]

lets revert it ! please create a PR

[chriskite]

Can do. Do we want to just revert it and go back to the previous approach of wrapping exceptions, or switch to a different approach like returning a Throwable as the error type?

[regis-leray]

@chriskite Lets remove all refineOrDie, thank you

Please change the signature to have

return type ZIO[R, Throwable, Unit]

def multipartUpload[R](
  bucketName: String,
  key: String,
  content: ZStream[R, Throwable, Byte],
  options: MultipartUploadOptions
)(parallelism: Int): ZIO[R, Throwable, Unit] 

Also can you do the changes for getObject

def getObject(bucketName: String, key: String): Stream[Throwable, Byte]

thank you