add option to mangle AC keys with (non-empty) instance names #339
+224
−115
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In some client setups, untracked local files can be used by an action without being included in the Action message, which causes action cache collisions: bazelbuild/bazel#4558 Ideally this should be fixed on the client side (either in the client, or in the build configuration), but it is not always easy to do in practice. As a workaround, this patch adds a setting to mangle ActionCache keys with the instance name provided by the client (if it is not empty), to produce a new ActionCache key. Clients are then able to specify a different instance name whenever a change is made that could affect these untracked inputs. The instance name value could be something like the hash of the compiler version. This allows multiple ActionCache items to exist in the cache, without requiring a change to the on-disk storage format. This feature is disabled by default, since it would cause cache invalidations for existing users. Fixes buchgr#15.
|
From a brief read, this looks great! I'll exercise it locally over the next day or two. |
kragniz
approved these changes
Aug 28, 2020
amartani
added a commit
to amartani/bazel-remote
that referenced
this pull request
Oct 21, 2022
buchgr#339 implemented AC key mangling based on instance name. However, that implementation missed applying the mangling logic on grpc UpdateActionResult method, causing cached entries to not match the ones fetched by GetActionResult. Correctly implement the feature on that method and add test to verify the new behavior.
amartani
added a commit
to amartani/bazel-remote
that referenced
this pull request
Oct 21, 2022
buchgr#339 implemented AC key mangling based on instance name. However, that implementation missed applying the mangling logic on grpc UpdateActionResult method, causing cached entries to not match the ones fetched by GetActionResult. Correctly implement the feature on that method and add test to verify the new behavior.
amartani
added a commit
to amartani/bazel-remote
that referenced
this pull request
Oct 21, 2022
buchgr#339 implemented AC key mangling based on instance name. However, that implementation missed applying the mangling logic on grpc UpdateActionResult method, causing cached entries to not match the ones fetched by GetActionResult. Correctly implement the feature on that method and add test to verify the new behavior.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In some client setups, untracked local files can be used by an action without being included in the Action message, which causes action cache collisions: bazelbuild/bazel#4558
Ideally this should be fixed on the client side (either in the client, or in the build configuration), but it is not always easy to do in practice.
As a workaround, this patch adds a setting to mangle ActionCache keys with the instance name provided by the client (if it is not empty), to produce a new ActionCache key. Clients are then able to specify a different instance name whenever a change is made that could affect these untracked inputs. The instance name value could be something like the hash of the compiler version. This allows multiple ActionCache items to exist in the cache, without requiring a change to the on-disk storage format.
This feature is disabled by default, since it would cause cache invalidations for existing users.
Fixes #15.