Nix-shell: [...] Assertion `request.expectedETag == res.etag' failed

Dear nix community,
As of today around noon, almost all my local default.nix / shell.nix suddenly stopped working, with the following obscure error message:

nix-shell: src/libfetchers/ nix::fetchers::DownloadFileResult nix::fetchers::downloadFile(nix::ref<nix::Store>, const string&, const string&, bool, const Headers&): Assertion `request.expectedETag == res.etag' failed.
[1]    20794 abort (core dumped)  nix-shell

After a while, I realized that I was still using*.tar.gz which I noticed recently was deprecated. The fix was to switch to*.tar.gz.
Actually this was not reproducible… so I am still looking for a fix…

I have no clue what could have prevented this, why this error message is so obscure and how to make the situation better. I am posting here mainly to reference my error message and the solution, with the hope other people could benefit from it.

I am completely lost, and I cannot work anymore :frowning:

Best wishes, has been deprecated, please use the release channels on nixos/nixpkgs. E.g.

Do you mind sharing it? assuming that there’s nothing sensitive

In the discord someone cited a similar error when they built their home manager config.

They have been on nixod-unstable IIRC and updated recently, though they also tried switching channels back and forth before, so I wasn’t really able to follow what was original intended channels and what was just desperate trying to fix things.

Looking through the code right now, I think this assertion is saying “I have an expired cache for this request. I sent the request to the remote server with the If-None-Match header set to the etag from my expired cache entry. I got back a 304 response, but it had an ETag that differed from what I expected”.

This should probably not be an assertion, because it means nix will crash if the remote server behaves in an unexpected fashion by sending back a 304 with a different ETag. Especially since AFAIK this is actually perfectly valid behavior; the server is saying “you already have the right content, but I want to give you a new ETag for it anyway”, which may happen if the server has a content-equivalent but not byte-equivalent resource, or if it wants to upgrade a weak ETag to a strong one. The client could in fact just ignore the ETag in the 304 response since it looks like it only retains one cached entry per key, though the preferable behavior is to update the cached response with the headers from the 304 response.

If you pass -vvvvv then it should print information about the http request (such as every header found in the result).

I’m getting this issue too when trying to use nix-shell, home-manager, nixos-rebuild, etc. Really anything that has to fetch something from the internet. I heavily rely on nix-shell to work, so if anyone has any idea on how to fix this please help. I am also not using that channel URL, so not that I’m afraid.

UPDATE: It seems to work if I disable flakes, so I’m going to leave that disabled for now.


1 Like

This happens in repository for example, here is a log that should be reproducible. Apparently you need flakes activated.

1 Like

Thanks! I deactivated flakes and I can work again.


rm ~/.cache/nix/fetcher-cache-v1.sqlite ~/.cache/nix/fetcher-cache-v1.sqlite-journal

does the work.