Need better error handling when there is a failure to fetch a file

[suhastech]

We stumbled upon a tricky bug where no matter what, the ZIP produced by zipline was corrupt. Tracking it down was quite difficult.

It seems that the download of one of the S3 files failed here:

https://github.com/fringd/zipline/blob/master/lib/zipline/zip_generator.rb#L96

file.download { |chunk| writer_for_file << chunk }
  S3 Storage (46.4ms) Downloaded file from key: 123
Traceback (most recent call last):]
Aws::S3::Errors::NotFound ()

Possible solutions:

• Aborting the download and raise the error properly with debug information. I'm not sure if this is possible as it's a stream.
• Write an empty file or with a note of the error. At least the other files would be properly delivered this way. I do agree this isn't ideal as it fails silently. An ignore errors flag from the user could make them aware.

[fringd]

yeah we should handle this better.

I'm not sure how, but if we could abort the whole download that's probably the best option...

[fringd]

i googled a bit for some possible solutions here... https://stackoverflow.com/questions/15305203/what-to-do-with-errors-when-streaming-the-body-of-an-http-request

these two options seem like the best leads:

2. Write a malformed chunk (and close the connection) which will trigger client error
3. Add a http trailer telling your client that something went wrong.

the trailer seems pretty robust, but i'm not sure how to do that.
https://www.rubydoc.info/gems/rack/Rack/Chunked is the only mention of trailers in rails i could find.

a malformed chunk? not sure how to make rails do that either.

if anybody else has any clues, let me know

[Urist-McUristurister]

Hey, just an idea, it may be stupid, but may be not, so...

If zipline fails to fetch a file, or any other error occurs:

• log this
• if it was a failure to fetch a file, add the file url to some kind of internal @skipped list
• if possible, do NOT add the failed file to archive. If not, better to have a working archive with a few broken files, than a whole broken archive. Especially if it's multiple GBs in size.
• move on to the next item on the list
• In the end, add a text file named, say, "failures.log", in which list the @skipped files with corresponding http errors

I don't know the internal mechanism of zipline, so, if skipping is not possible, then write the closing sequence for the broken file (if needed/possible), write the "failures.log", and finish up with proper zip header (well, footer, technically) - to allow client to unarchive at least what have been fetched so far.

Optionally, add a configuration/options/settings/initialiser to customise the name and content (using proc) of the failures log file (or disable it completely).

WDYT?...

[fringd]

this might be possible if the failure happened at the beginning. if it happened in the middle of the file that data has already been streamed out to the user and it's not possible to walk it back as far as i know. i think i'd rather abort than have a chance that the user thinks this file is valid.

…

On Wed, Jun 21, 2023 at 3:38 AM Urist McUristurister < ***@***.***> wrote: Hey, just an idea, it may be stupid, but may be not, so... If zipline fails to fetch a file, or any other error occurs: - log this - if it was a failure to fetch a file, add the file url to some kind of internal @Skipped list - if possible, do NOT add the failed file to archive. If not, better to have a working archive with a few broken files, than a whole broken archive. Especially if it's multiple GBs in size. - move on to the next item on the list - In the end, add a text file named, say, "failures.log", in which list the @Skipped files with corresponding http errors I don't know the internal mechanism of zipline, so, if skipping is not possible, then write the closing sequence for the broken file (if needed/possible), write the "failures.log", and finish up with proper zip header (well, footer, technically) - to allow client to unarchive at least what have been fetched so far. Optionally, add a configuration/options/settings/initialiser to customise the name and content (using proc) of the failures log file (or disable it completely). WDYT?... — Reply to this email directly, view it on GitHub <#78 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCSRKTWH6YT5OECDUXJ7DXMKQJFANCNFSM45UQOWHA> . You are receiving this because you commented.Message ID: ***@***.***>

[fringd]

that said, an errors.log would be better than nothing. i'll keep this in mind if we try the other options and can't get them working.

[Urist-McUristurister]

if it happened in the middle of the file that data has already been streamed out to the user and it's not possible to walk it back as far as i know

But there's no need to walk back.

Before switching to zipline, for many years we've used a "classic" approach of downloading files to the worker machine, zipping them, and then sending to the client. And from that experience, vast majority of errors related to remote files happen when trying to fetch a file - for example, a 404 or 5XX, or any other type of error. For something to happen when the remote file is in the middle of transfer - I can't say that I have ever encountered this. So if it's possible to just log it and skip it - that would be best.

But even in the case where we've fetched, say, 20mb out of 25mb file, and in the middle of transfer the connection to remote host went down or timed out — is it possible to stream to the client "ok, that's the end of this file, here's the next one" and just jump to the next file in the list? Because it is still much more preferable to have a log + corrupted 20mb file + 1999 full files, rather than a broken 15Gb archive that you can't even examine nor salvage.

[fringd]

yeah actually that makes some sense to me... this gem is mostly for those giant downloads, so maybe just getting partial success is generally better. my worry is the user will not know that the 1 file in there is actually corrupt.

[Urist-McUristurister]

my worry is the user will not know that the 1 file in there is actually corrupt.

Hence the error.log ;) Better 1 corrupt file, than 15gb corrupt archive...

[julik]

The problem is that a ZIP file which has been "chopped off" at the end is likely not to unarchive well, because the list of files inside the ZIP comes at the end of file. You can read the ZIP "straight-ahead" but in presence of data descriptors this is likely to fail on some apps, and it is very inefficient. It can also be faulty - for example, if entries are themselves ZIP files. What you need to make this work is a resumable download, similar to what we've done at WeTransfer back in the day. You might be able to put something together using raw zip_tricks and interval_response so that when you address the download again you will be able to resume your download. It is not trivial to do by any means but doable.

error.log would be a nice feature, albeit that when your download interrupts you already can't add anything to the response.

But even in the case where we've fetched, say, 20mb out of 25mb file, and in the middle of transfer the connection to remote host went down or timed out — is it possible to stream to the client "ok, that's the end of this file, here's the next one" and just jump to the next file in the list?

If your concern is the "upstream" (where you are pulling the file from) timing out on you or similar, you can pull data from it in chunks and resume where it interrupts. HTTP Range headers can be used for that.

[Urist-McUristurister]

@julik I'm not talking about "chopping off" zip files, I'm talking about chopped off files that are being requested. Or, which is actually more frequent, non existing, 404 files, that zipline is fetching from the url. If I specify a list of 500+ urls (S3, for example), and one of them in the middle of the list does not exist, then the whole 50gb archive is botched. And the frustration about downloading 30Gb file which is suddenly broken, and then you try to download it again, just to find out that it's still broken, is immense.

I'm not talking about chopping the zip file. I'm talking about at least skipping the failed archivable file. If the file being fetched is throwing an error, any error, then either skip writing it altogether or write what have been fetched so far (say, 50mb of 150), if it's a partially fetched file, and move on to the next file. And in the very end, in the list of the zipped files, say "ok, this file is 50mb in size, next".

That way when user downloads the archive, it will have only 1 file in the whole archive "broken" (zero-sized, partial, or not present at all), not the whole archive itself.

[julik]

That should actually work if you surround your call to write_deflated_file with a block with a rescue. If you do that, zip_tricks will move on to the next file and not add the file you have written to the central directory. The likelihood is high that the unarchiving software opening the file will be able to unarchive correctly based on the central directory, which gets output in the end. Try adding a rescue surrounding ZipGenerator#write_file and try with some large-ish outputs interrupting them halfway?

Update - I was wrong, because even though ZipTricks will not finalize the file it will still add it to the central directory - albeit in a "broken" form. You would need to muck about with the internals a bit:

module SaferZipWrite
  # Removes a file that does not finish writing from the
  # @files array in the Streamer, so that the file will not
  # be present in the ZIP central directory. Some unarchivers
  # might then still be able to unarchive files which do complete writing.
  class StreamerWrapper < SimpleDelegator
    def write_deflated_file(...)
      files = __getobj__.instance_variable_get("@files")
      n_files_before_writing = files.size
      super
    rescue => e
      # do something with the exception
      files.pop if files.size > n_files_before_writing
    end

    def write_stored_file(...)
      files = __getobj__.instance_variable_get("@files")
      n_files_before_writing = files.size
      super
    rescue => e
      # do something with the exception
      files.pop if files.size > n_files_before_writing
    end
  end

  def write_file(streamer, file, name, options)
    super(StreamerWrapper.new(streamer), file, name, options)
  end
end

Zipline::ZipGenerator.prepend(SaferZipWrite)

[Urist-McUristurister]

Well... I actually did something similar: I've patched the write_file method to first attempt the download of the target file, with up to 3 retries, in case of failure after 3 retries write a text file with a same name and error message, and then proceed with that file to streamer.write_stored_file (stored because we're serving pictures mostly, no BMPs, so it doesn't really make much sense to compress them even further. A "compression" option for zipline method, maybe?). Sure, it's slower, since it has to download the file first, but more reliable. Still, not something that would be fit for everyone.

I'll try your suggestion, though, thanks! 👍 Maybe I don't have to download the whole file after all...

Still, would be nice to have this feature built-in ;)

[Urist-McUristurister]

even though ZipTricks will not finalize the file it will still add it to the central directory - albeit in a "broken" form

That's still much more preferable than a broken archive! 👍 😉

[julik]

"compression" option for zipline method, maybe?

that is for @fringd to ponder 😆 The feature would be nice, indeed - I'd wager it would have to be added in zip_tricks though and I haven't yet sorted the maintenance there. There could be a heuristic in zipline where it picks stored or deflated depending on the filename extension for instance. Note that storing a stored Excel or Word file can lead to interesting bugs because if a program reads a ZIP "straight ahead" it will sometimes think that the parts of those Office files are themselves entries of the "outer" ZIP 🤡 I remember the macOS ArchiveUtility used to do this, but don't know at which version they have fixed it.

[fringd]

PRs welcome of course. I'm assuming there isn't enough local storage for files generally though, so anything that waits for a whole file before continuing is a non-starter 😕 1. Maybe we could just abandon the data and remove the failed file from the list of central directory entries. Even include an "ERRORLOG.txt" file or something in the archive saying that one or more files failed to fetch. i'm not 100% sure, but i think it's valid to have a bunch of garbage data in the zip file that is never pointed to by the central directory entries. 2. Code that at least attempts to recover if the download fails would be welcome... trying to restart or resume and continue feeding data into the output stream some way without abandoning the written data... or alternatly abandon the already written data, again discarding the central directory entry, but this time adding a new one and starting over and hoping this works. 3. i think the cost of deflating files that don't benefit is negligible, so it's probably not worth the trouble to do any fancy extension heuristics