Vendor mode uses wrong checksum for patch files

[peakschris]

Description of the bug:

When using vendor mode for a build, the following warning and error is seen:

WARNING: <builtin>: Vendored repository 'rules_dotnet~' is out-of-date. The up-to-date version will be fetched into the external cache and used. To update the repo in the  vendor directory, run 'bazel vendor'
WARNING: Download from file:/E:/workdir/devunits/cb_ci_bazel1/offline/bazel-central-registry/modules/rules_dotnet/0.14.0/patches/module_dot_bazel_version.patch failed: class com.google.devtools.build.lib.bazel.repository.downloader.UnrecoverableHttpException Checksum was sha256-DpImBeI9ue3XFoAYNIFoI9WObmW5SQDhJrR34tflBK8= but wanted sha256-0BsPROWCJN7risga/ocBOF1BsWyAKHCdOk7VtG8cSKA=
ERROR: An error occurred during the fetch of repository 'rules_dotnet~':
   Traceback (most recent call last):
        File "E:/udu/b/krpmqu3z/external/bazel_tools/tools/build_defs/repo/http.bzl", line 135, column 45, in _http_archive_impl
                download_info = ctx.download_and_extract(
Error in download_and_extract: java.io.IOException: Error downloading [file:/E:/workdir/devunits/cb_ci_bazel1/offline/bazel-central-registry/modules/rules_dotnet/0.14.0/patches/module_dot_bazel_version.patch] to E:/udu/b/krpmqu3z/external/rules_dotnet~/temp10822939975339865198/module_dot_bazel_version.patch: Checksum was sha256-DpImBeI9ue3XFoAYNIFoI9WObmW5SQDhJrR34tflBK8= but wanted sha256-0BsPROWCJN7risga/ocBOF1BsWyAKHCdOk7VtG8cSKA=

The relevant file (bazel-central-registry/modules/rules_dotnet/0.14.0/source.json is:

{
    "integrity": "sha256-0BsPROWCJN7risga/ocBOF1BsWyAKHCdOk7VtG8cSKA=",
    "strip_prefix": "rules_dotnet-0.14.0",
    "url": "https://github.com/bazelbuild/rules_dotnet/releases/download/v0.14.0/rules_dotnet-v0.14.0.tar.gz",
    "patches": {
        "module_dot_bazel_version.patch": "sha256-DpImBeI9ue3XFoAYNIFoI9WObmW5SQDhJrR34tflBK8="
    },
    "patch_strip": 1
}

It looks like the code is using the module's own integrity value to validate the patch file, which is incorrect and fails.

The out of date message is also incorrect; the module is freshly vendored.

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

No response

Which operating system are you running Bazel on?

windows

What is the output of bazel info release?

release 7.2.0 (near latest - 8c6220a)

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[peakschris]

This seems to be an issue only when the registry is located at a file url:

common --registry=file:///%workspace%/bazel-central-registry

@Wyverald

[peakschris]

My current thinking is that this might be a bad interaction between the file:///%workspace% URL supplied to the --registry option and experimental_downloader_config (I'm using both). I'm not sure if file URLs are caught by the downloader, or what the syntax would be to allow them, since matching occurs without the protocol prefix. I don't know if there is a way to log what the downloader is doing to fetches in order to figure out what's going on.