| 22 Jun 2026 |
 Mic92 | @hexa:lossy.network: I think it actually requires a new eval for my change to have an effect. Testing this now. At least error messages are a lot clearer now. | 05:20:32 |
| Mic92 | https://hydra.nixos.org/eval/1826477#tabs-unfinished that's the eval that will show if it worked. | 05:37:45 |
| Mic92 | Bumped to the front so we make progress quickly | 05:38:14 |
 Vladimír Čunát | Two catches:
- it was 1-2 days, but note that starting the eval happens immediately after the merge, so that is the point where the git hash gets fixed already, even if the channel advances to it a day or two later
- the new queue runner appears to be way way faster in this respect
| 05:44:51 |
| Vladimír Čunát | Looks the same, I'm afraid. | 05:54:33 |
| Mic92 | @vcunat:matrix.org: yeah. It was able to clear out some of the previous errors. But now at least I have more recent logs to figure out why the cache is not giving us what we just build. | 05:57:31 |
| Vladimír Čunát | Thanks for working on these issues. It's not nice to block channels for too long. | 05:58:21 |
| Mic92 | Is fastly doing negative caching? | 05:58:45 |
| Vladimír Čunát | Even if it isn't, nix does it locally. | 06:03:37 |
| Mic92 | I think I disabled that already | 06:04:02 |
| Vladimír Čunát | (I'm not sure about Fastly, but I think that short negative cache is desirable there as well.) | 06:04:03 |
| Mic92 | Yeah. Worst comes to worse and we have to add the s3 bucket as a secondary substituter | 06:04:41 |
| Vladimír Čunát | http headers should releval if it's cached? | 06:05:04 |
| Mic92 | Checking now | 06:06:14 |
| Vladimír Čunát | $ curl -s https://cache.nixos.org/gypp7g48p2fcpjx952i84dhw4ak95np1.narinfo --show-headers
HTTP/2 404
server: Varnish
retry-after: 0
content-type: text/plain
accept-ranges: bytes
date: Mon, 22 Jun 2026 06:06:44 GMT
via: 1.1 varnish
x-served-by: cache-vie6368-VIE
x-cache: MISS
x-cache-hits: 0
access-control-allow-origin: *
content-length: 3
404⏎
| 06:07:03 |
| Vladimír Čunát | Doesn't look cached to me. | 06:07:07 |
| Vladimír Čunát | (tried a few times) | 06:07:17 |
| Mic92 | Or it is | 06:07:58 |
| Vladimír Čunát | I even managed to get a repeated x-served-by | 06:08:20 |
| Vladimír Čunát | Now I'm force-updating the nixos-26.05 channel to e8210c649915 / https://hydra.nixos.org/build/331669102 | 06:51:28 |
 Arian | Nope we don't do negative caching. That was very much on purpose iirc? | 06:55:10 |
| Vladimír Čunát | It's certainly not a problem not to cache those, as long as it doesn't cost us much. | 06:56:59 |
| Vladimír Čunát | * It's certainly fine not to cache those, as long as it doesn't cost us much. | 06:57:11 |
| Vladimír Čunát | Also this one, it was 7 days old commit
8c14fa3ccacd..ea68a74f45ad nixpkgs-26.05-darwin
| 08:25:24 |
| Mic92 | https://github.com/NixOS/infra/pull/1097 with this we got now release-26.05-small back to green: https://hydra.nixos.org/eval/1826486 | 09:54:01 |
| Arian | In reply to @vcunat:matrix.org
It's certainly fine not to cache those, as long as it doesn't cost us much. We do get charged for 404s and 200s just the same.
Idk what the ratio between uncached 404s and 200s is. We can look this up in fastly.
Caching 404s definitely saves money. But idk how much.
But we currently don't cache them exactly so that we don't have read after write inconsistencies. | 10:01:42 |
| Vladimír Čunát | I don't think the old queue-runner would mind. | 10:02:32 |
| Vladimír Čunát | (it wasn't pulling from Fastly IIRC) | 10:02:46 |
| Vladimír Čunát | I don't expect it's a major concern right now anyway. | 10:03:24 |
| Vladimír Čunát | Maybe a future TODO to investigate. | 10:03:29 |
