harmonia
harmonia copied to clipboard
My nix queries /nar/<hash>-<name>.narinfo, not just /<hash>.narinfo
My nix 2.15.1 queries /nar/<hash>-<name>.narinfo
for some reason, so I had to
location ~ "^/nar/([a-z0-9]{32})-.*\.narinfo$" {
proxy_pass http://127.0.0.1:5000/$1.narinfo$is_args$args;
...
}
(It was worth to set it up though, I've seen ~10x speedups in synthetic local tests vs whatever's built into hydra.)
Sadly, this workaround didn't work for me on 2.16 (nix-serve doesn't work either for some reason). A new URL format seems to have been added again, this time it looks like nar/yy5li73s8bxjbmax8slbwg8a7sji3dlw-11nzfcccqldbfdpw4mmbxdjp29jaimvkmdsc1cz6xnadlcjqna1n.nar
Edit: it seems to be implemented here
Out of curiosity, was this a case where you did a drop in replacement of nix-serve -> harmonia?
What I found after doing that was that the harmonia-backed cache worked fine in fresh environments like new containers, but it was a problem for existing installs that seemed to have cached the nix-store-info
data and weren't periodically re-fetching it. We were able to use nginx mapping rules to satisfy the old requests, but it would be nice if Harmonia would just exactly copy what nix-serve does in this regard.
Hm, solid theory! I've removed the redirect now (~5 days later) and I can't reproduce the issue anymore.
This isn't really resolved as the root cause still hasn't been found (and I've implemented hash-hash.nar, not hash-name.narinfo), #122 is just a fix for a related issue @Mic92
I don't see these types of queries and I also don't see in the nix code base any code that would generate /nar/<hash>-<name>.narinfo
type paths. Here for your reference: https://github.com/search?q=repo%3ANixOS%2Fnix+.narinfo+lang%3AC%2B%2B+&type=code
We are testing now with nix 2.17 and I don't see any issues.
That sounds like a narinfo caching artifact. To quote the documentation from narinfo-cache-positive-ttl
: The default TTL is a month
.
For .nar urls this makes sense but not for .narinfo files