#[non_exhaustive]pub struct CacheConfig {
pub enabled: bool,
pub fetch_timeout_secs: u64,
pub max_concurrent_fetches: usize,
}Expand description
Configuration for HTTP caching behavior.
Controls cache settings for registry requests. The cache uses ETag and Last-Modified headers for validation, minimizing network traffic.
§Defaults
enabled:truefetch_timeout_secs:10(10 seconds per package)max_concurrent_fetches:20(20 concurrent requests)
§Examples
use deps_core::policy_config::CacheConfig;
let config = CacheConfig::new()
.with_fetch_timeout_secs(5)
.with_max_concurrent_fetches(20);
assert_eq!(config.fetch_timeout_secs, 5);Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.enabled: boolWhether deps_core::cache::HttpCache’s entry map is used at all (issue #482):
false bypasses it entirely (fetch fresh every time, never store).
Offline override: while network.offline (see NetworkConfig::offline) is
set, this flag’s false value is overridden and treated as true — otherwise a
warm entry fetched before going offline could never survive an online→offline
transition, since nothing would have been stored while online in the first place.
Maven exception: deps-maven’s peek_cached-based stale-data fallback
(crates/deps-maven/src/registry.rs) behaves differently from every other
ecosystem under enabled: false, which has no equivalent second-layer fallback to
diverge on. This only “always misses” for a process that started cold with the
flag already off — peek_cached reads the entry map directly and
set_cache_enabled never clears it, so a live true -> false toggle leaves
every already-stored entry servable through this fallback indefinitely.
fetch_timeout_secs: u64Timeout for fetching a single package’s versions (default: 10 seconds)
max_concurrent_fetches: usizeMaximum concurrent package fetches (default: 20)
Implementations§
Source§impl CacheConfig
impl CacheConfig
Sourcepub const fn new() -> Self
pub const fn new() -> Self
Builds the default configuration (mirrors Self::default).
§Examples
use deps_core::policy_config::CacheConfig;
let config = CacheConfig::new();
assert!(config.enabled);Sourcepub const fn with_enabled(self, enabled: bool) -> Self
pub const fn with_enabled(self, enabled: bool) -> Self
Overrides Self::enabled. See Self::new.
Sourcepub const fn with_fetch_timeout_secs(self, fetch_timeout_secs: u64) -> Self
pub const fn with_fetch_timeout_secs(self, fetch_timeout_secs: u64) -> Self
Overrides Self::fetch_timeout_secs. See Self::new. Not clamped to the
bounds deserialize_fetch_timeout enforces — that validation only guards
untrusted LSP-client input, not construction from trusted Rust code.
Sourcepub const fn with_max_concurrent_fetches(
self,
max_concurrent_fetches: usize,
) -> Self
pub const fn with_max_concurrent_fetches( self, max_concurrent_fetches: usize, ) -> Self
Overrides Self::max_concurrent_fetches. See Self::new. Enforces the same
>= 1 floor (MIN_CONCURRENT_FETCHES) that deserialize_max_concurrent enforces
on untrusted LSP-client input — but, unlike that deserializer, does not also cap the
MAX_CONCURRENT_FETCHES ceiling, so a very large value passes through uncapped: this
value is used directly as futures::StreamExt::buffer_unordered’s concurrency limit
(document::fetch), and buffer_unordered(0) never polls its source stream, hanging
the fetch forever instead of erroring (issue #833) — unlike
Self::with_fetch_timeout_secs, 0 here is not a merely degenerate value, so this
setter enforces the floor itself rather than relying on a downstream re-guard
(handlers::diagnostics::loading_ceiling also re-guards its own divisor, but that is
a second, independent consumer, not a safety net for this one).
§Examples
use deps_core::policy_config::CacheConfig;
let config = CacheConfig::new().with_max_concurrent_fetches(0);
assert_eq!(config.max_concurrent_fetches, 1);