The Storage trait has a check method that returns whether the cache is able to Read/Write or Read-only[1]. When the method is able to do that determination without an error, the code in start_server then proceeds with displaying server has setup with {cache_mode:?}[2] and... nothing else. Which means when the check says only Read-only is supported, cache writes are still attempted.

1. sccache/src/cache/cache.rs

   Lines 352 to 354 in 7074753

   	async fn check(&self) -> Result<CacheMode> {
   	Ok(CacheMode::ReadWrite)
   	}

2. sccache/src/server.rs

   Lines 423 to 440 in 7074753

   	let cache_mode = runtime.block_on(async {
   	match storage.check().await {
   	Ok(mode) => Ok(mode),
   	Err(err) => {
   	error!("storage check failed for: {err:?}");
   	notify_server_startup(
   	&notify,
   	ServerStartup::Err {
   	reason: err.to_string(),
   	},
   	)?;
   	Err(err)
   	}
   	}
   	})?;
   	info!("server has setup with {cache_mode:?}");

Side note, this is actually quite fortunate for us, because at least in the case of GCS, the check requires delete permissions to overwrite the .sccache_check file, which our sccache clients don't have (which means SCCACHE_RECACHE doesn't work on this setup...). So while our logs do complain about the lack of delete permissions, and say "server has setup with ReadOnly", cache misses are properly filled after local compile...

So what this means is that at least in the case of GCS, the check is actually checking whether recaching (SCCACHE_RECACHE) would work, rather than whether the cache would work, although the very first time (when the .sccache_check file is not in the bucket), it would do the latter.