Unhelpful error message when using the wrong sha in http_archive()

[hansl]

Using the wrong SHA in http_archive() will result in the following message (using rules_nodejs as an example):

$ bazel build //...
INFO: Starting clean.
Starting local Bazel server and connecting to it...
..............
ERROR: error loading package '': Encountered error while reading extension file 'internal/common/check_version.bzl': no such package '@build_bazel_rules_nodejs//internal/common': Prefix rules_nodejs-0.12.2 was given, but not found in the zip
ERROR: error loading package '': Encountered error while reading extension file 'internal/common/check_version.bzl': no such package '@build_bazel_rules_nodejs//internal/common': Prefix rules_nodejs-0.12.2 was given, but not found in the zip
INFO: Elapsed time: 1.645s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)

This fails to give me any relevant information to the error. Instead, it gives me actual misinformation (that the zip doesn't contain the prefix, which is wrong).

A better error message would include wording such as "the ZIP downloaded does not match the SHA expected".

[ittaiz]

This is a duplicate. Don’t remember the other issue but you can search for it

…

On Wed, 5 Sep 2018 at 22:22 Hans ***@***.***> wrote: Using the wrong SHA in http_archive() will result in the following message (using rules_nodejs as an example): $ bazel build //... INFO: Starting clean. Starting local Bazel server and connecting to it... .............. ERROR: error loading package '': Encountered error while reading extension file 'internal/common/check_version.bzl': no such package ***@***.***_bazel_rules_nodejs//internal/common': Prefix rules_nodejs-0.12.2 was given, but not found in the zip ERROR: error loading package '': Encountered error while reading extension file 'internal/common/check_version.bzl': no such package ***@***.***_bazel_rules_nodejs//internal/common': Prefix rules_nodejs-0.12.2 was given, but not found in the zip INFO: Elapsed time: 1.645s INFO: 0 processes. FAILED: Build did NOT complete successfully (0 packages loaded) This fails to give me any relevant information to the error. Instead, it gives me actual misinformation (that the zip doesn't contain the prefix, which is wrong). A better error message would include wording such as "the ZIP downloaded does not match the SHA expected". — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6089>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF9oy4lNgLi2gq7Gbe-2PdaipgsXsks5uYCSGgaJpZM4WbihR> .

[irengrig]

Hi! Thank you for reporting the issue.
Actually the message that you copied complains about wrong prefix:
"ERROR: error loading package '': Encountered error while reading extension file 'internal/common/check_version.bzl': no such package '@build_bazel_rules_nodejs//internal/common': Prefix rules_nodejs-0.12.2 was given, but not found in the zip"
and not about the SHA, seems the SHA was correct (the issue about improving the SHA message: #3709)

I was also recently thinking that maybe we should also suggest what probable value of the prefix should be, it is easy to detect. Did you mean that?

[hansl]

No. The only thing I changed to fix this error was the SHA argument in http_archive. Nothing else was involved.

[irengrig]

Can not reproduce that. I tried to change the SHA in my example to incorrect value and it complains about SHA. Can you provide more information? Thank you.

[Globegitter]

I imagine that probably a valid sha was entered of an archive that existed in the cache, so bazel loaded that but the contents did not match. As far as I am aware @aehlig is doing work on that topic, that bazel actually verifies the sha of remote repositories and does not just rely on the one specified.

[irengrig]

I see, thank you!

[aehlig]

This is a bit of a tricky issue, as technically it is working as intended: bazel should avoid all call outs to the network, if it can. Now, if a hash is provided, this is not only a security measure, but also a promise to bazel that any file with that hash will do, no matter where it is fetched from. So the cache hit is legitimate and calling out to the network just to improve the error message in case the user made a mistake in the WOKRSPACE file is not a good experience.

Now, I don't know of any good semantics for bazel that would improve the error message without adding additional cost on the non-error case. And I don't like optimising the error case at the cost of the normal case. If you have an idea how bazel could behave better (again: without degrading the non-error case), feel free to file a feature request or reopen this issue with more details.

[aehlig]

This is a duplicate. Don’t remember the other issue but you can search for it

Probably #5144

[aehlig]

...or #5045