mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-20 01:07:18 +03:00
9da40ea426
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 |
||
|---|---|---|
| .. | ||
| cron | ||
| da-ghc-lib | ||
| docker | ||
| patch_bazel_windows | ||
| bash-lib.yml | ||
| build-unix.yml | ||
| build-windows.yml | ||
| build.yml | ||
| check-changelog.sh | ||
| clean-up.yml | ||
| clear-shared-segments-macos.yml | ||
| compatibility_ts_libs.yml | ||
| compatibility-windows.yml | ||
| compatibility.yml | ||
| configure-bazel.sh | ||
| daily_tell_slack.yml | ||
| dev-env-install.sh | ||
| dev-env-push.py | ||
| postgresql.conf | ||
| prs.yml | ||
| report-end.yml | ||
| report-start.yml | ||
| slack_user_ids | ||
| tell-slack-failed.yml | ||
| windows-diagnostics.ps1 | ||