Wouldn't this still fail in copyStorePath(), if BinaryCacheStore::narFromPath() returns a NAR with an unexpected hash? Deleting it from the database will only make it work on the next invocation.

The use case here is that there's a GC on the binary cache meanwhile. So there won't be nar nor narinfo, while Nix will have cached narinfo.

That's why we fallback to deleting the cache entry on 404 and retry.

The case where nar is corrupted is already being handled and if it's not corrupted it should just work?

@edolstra does that clear up the motivation?

The motivation is clear. I was asking about how this works. How is it that copyStorePath() and SubstitutionGoal don't fail if narFromPath() returns a NAR with an unexpected hash?

NoSuchBinaryCacheFile exception is raised inside narFromPath because the nar is missing in the binary cache.

That's when we refresh the narinfo and retry fetching the new nar (the optimization could be to check if nar url differs and not re-fetch it)

Note that this would allow deleting nar files that are younger than 30 days, currently that results into Nix not recovering without deleting binary cache sqlite file.

@edolstra I'm stuck here as I don't understand your questions.

I marked this as stale due to inactivity. → More info

I closed this issue due to inactivity. → More info