Open desavitsky opened 1 year ago
Currently multipart upload files are deleted when there's a decode failure on the body: https://github.com/softwaremill/tapir/blob/c3f45cbbd38830eb41c41cddde0ca8f283c6efb5/server/core/src/main/scala/sttp/tapir/server/interpreter/ServerInterpreter.scala#L173-L176
Arguably this could be extended so that the files are deleted if there is a decode failure (e.g. an exception during a .map
) at a later stage as well.
However, so far the assumption was that when we invoke the server logic, it's up to the user to decide what to do with those files - whether to delete them, keep them, move, etc. I'm not sure if deleting is a safe default - I guess people might rely on these file staying in their original locations after the request completes?
Well, that's possible that people might rely on these files, but kinda strange From my point of view, the thing that file is written to disc is the internal part of backend processing the multipart request, and it should not be the part of the logic Maybe it is possible to allow users to customize it? For example, add extra field to VertxZioServerOptions vertxHandlerOptions and let users change it if they need it?
Also, I think it is needed to be added to docs, because this behaviour was a surprise for me:)
Tapir version: zio-vertx-1.1.1
Scala version: 2.13.8
Files regardless of their size are saved on disk and not deleted after request is completed. Had to delete them manually They are saved in folder in project root ./file-uploads
code to reproduce: