ci/cron: fix retry policy (#8985)

I think the retry is clobbering the files. Here is my theory:
- The HTTP request is lazy, i.e. it starts producing a byte stream
  before it has finished downloading.
- The connection somehow crashes in the middle of that lazy handling,
  possibly because the Haskell code blocks for too long on something
  else and GCP thus closes the connection. (If this is true, making sure
  we download the entire thing before we start writing may make the
  download more reliable.) This explains why we get a "resource vanished"
  and not a plain 404 to start with.
- The retry policy doesn't know anything about HTTP requests; it just
  sees an IO action throwing an exception and restarts the whole thing.
- Because the IO action opens the file in Append mode, we thus end up
  with a file that is too big and has its "starting bytes" multiple
  times. That obviously fails to sign-check.

If this is what happens then the retry does not help at all, which does
seem to be what we've been observing (though I haven't tracked the exact
error rate too closely). The fix would likely be as simple as changing
`IO.AppendMode to IO.WriteMode (which truncates, per [documentation]).

[documentation]: https://hackage.haskell.org/package/base-4.14.1.0/docs/System-IO.html

CHANGELOG_BEGIN
CHANGELOG_END
This commit is contained in:
Gary Verhaegen 2021-03-02 14:51:00 +01:00 committed by GitHub
parent 65101e37d0
commit 9da40ea426
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -341,7 +341,7 @@ download_assets tmp release = do
status
downloadFile req manager url = HTTP.withResponse req manager $ \resp -> do
let body = HTTP.responseBody resp
IO.withBinaryFile (tmp </> (last $ Network.URI.pathSegments url)) IO.AppendMode $ \handle -> do
IO.withBinaryFile (tmp </> (last $ Network.URI.pathSegments url)) IO.WriteMode $ \handle -> do
while (readFrom body) (writeTo handle)
verify_signatures :: FilePath -> FilePath -> String -> IO ()