Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GRPC proxy failure to another bazel-remote expected magic number not found #751

Closed
liam-baker-sm opened this issue May 29, 2024 · 2 comments · Fixed by #752
Closed

GRPC proxy failure to another bazel-remote expected magic number not found #751

liam-baker-sm opened this issue May 29, 2024 · 2 comments · Fixed by #752

Comments

@liam-baker-sm
Copy link

Setup:
Local test server in docker container, compressed storage (zstd).
Remote server, compressed storage (zstd)
Version: 2.4.4
bazel_remote_arguments (local test server): --max_size=100 --grpc_proxy.url=grpcs://bazel-cache.domain:8443
Upstream fetches fail with the following error (note: real object hash replaced with the empty hash for confidentiality)

2024/05/29 01:14:07 GRPC PROXY READ CAS e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: Completed
2024/05/29 01:14:07 GRPC BYTESTREAM READ FAILED: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 expected magic number not found

Works fine if using
--max_size=100 --http_proxy.url=https://bazel-cache.domain --storage_mode=uncompressed
Bazel builds use the GRPCS url without issue.

@liam-baker-sm liam-baker-sm changed the title GRPC proxy failure expected magic number not found GRPC proxy failure to another bazel-remote expected magic number not found May 29, 2024
@mostynb
Copy link
Collaborator

mostynb commented May 29, 2024

Thanks for the bug report- I pushed a fix to the master branch.

@gdh1995
Copy link

gdh1995 commented Aug 29, 2024

Updated: Sorry it seems that I mistakenly understood it. The header belongs to a "skippable frame" so it doesn't affect decompressing, does it?

Hello, I noticed the fix for this solution changed a very deep logic about how to returning a zstd-compressed blob, and is incompatible with previous versions.

I wonder if we may add an extra field (like HTTP header) to tell a bazel-remote backend to return a zstd stream with the header or without it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants