You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In remote cache mode, a local-only Store is passed to the process_execution::local::CommandRunner to isolate it from failures in a configured remote CAS. The remote cache code then wraps the upload of digests so that errors in accessing the remote CAS only warn and do not error.
As it turns out, however, some intrinsics use the Store on Core to access the CAS and that Store is the instance configured with access to the remote CAS. Thus, certain code paths that run outside of the context of process_execution::local::CommandRunner are not covered by the warning code in the remote cache code.
A particular example is the download_file_to_digest intrinsic. See
// If remote caching is used with eager_fetch, we do not want to use the remote store
// with the local command runner. This reduces the surface area of where the remote store is
// used to only be the remote cache command runner.
let store_for_local_runner = if remote_caching_used && remoting_opts.cache_eager_fetch{
store.clone().into_local_only()
}else{
store.clone()
};
that the local-only Store is passed only to the process_execution::local::CommandRunner. Intrinsics are not covered by this behavior.
The solution should audit for store accesses that are not covered by the local-only store and that should be. Manually fixing each call site is likely to be a game of whack-a-mole, so a generic solution that intrinics can use is probably preferred.
The text was updated successfully, but these errors were encountered:
tdyas
changed the title
non-remote-cache uses of CAS should degrade gracefully in remote cache mode
non-local runner uses of CAS should degrade gracefully in remote cache mode
Jan 13, 2021
### Problem
As described in #11455, in remote cache mode with eager fetching, the only accesses to the remote CAS should be through the remote cache code; the remainder of the Pants code base should only see the local store. Intrinsics, such as download_file_to_digest, still have access to the remote CAS currently, which means that any issues with the remote CAS will cause an error instead of being a warning if the access to the remote CAS had occurred through the remote cache code. The intended behavior is for all problems with the remote CAS to be warnings when in remote cache mode.
### Solution
In remote cache mode with eager fetching, only expose the local store to most of the Pants code base.
### Result
Added an integration test to test that warnings are generated in remote cache mode.
Fixes#11455
In remote cache mode, a local-only Store is passed to the
process_execution::local::CommandRunner
to isolate it from failures in a configured remote CAS. The remote cache code then wraps the upload of digests so that errors in accessing the remote CAS only warn and do not error.As it turns out, however, some intrinsics use the
Store
onCore
to access the CAS and thatStore
is the instance configured with access to the remote CAS. Thus, certain code paths that run outside of the context ofprocess_execution::local::CommandRunner
are not covered by the warning code in the remote cache code.A particular example is the download_file_to_digest intrinsic. See
pants/src/rust/engine/src/nodes.rs
Lines 699 to 721 in 9cf2573
core.store()
to get theStore
stored on theCore
struct.Note in
pants/src/rust/engine/src/context.rs
Lines 217 to 224 in 592d96c
process_execution::local::CommandRunner
. Intrinsics are not covered by this behavior.The solution should audit for store accesses that are not covered by the local-only store and that should be. Manually fixing each call site is likely to be a game of whack-a-mole, so a generic solution that intrinics can use is probably preferred.
The text was updated successfully, but these errors were encountered: