running nix-channel --update twice does not update the second time

[Radvendii]

Describe the bug

If you run nix-channel --update, and then update a channel upstream and run nix-channel --update again, it will not pull the update. It seems to be hitting the fetcher cache.

Steps To Reproduce

$ gh repo create foo --public --clone
$ cd foo
$ echo 1 > bar
$ git commit . -m "initial commit"
$ git push
$ nix-channel --add https://github.com/<your-user>/foo/archive/master.tar.gz foo
$ nix-channel --update
$ nix repl
> builtins.readFile <foo/bar>
"1\n"

So far so good. this is what we would expect, but then, back at the command line...

$ echo 2 > bar
$ git commit . -m "update bar"
$ git push
$ nix-channel --update
$ nix repl
> builtins.readFile <foo/bar>
"1\n"

Uh oh! no update.

If we run nix-channel --update -vvvvvv, it shows:

using cache entry 'file:{"name":"master.tar.gz","store":"/nix/store","url":"https://github.com/<user-name>/foo/archive/master.tar.gz"}' -> '{"etag":"W/\"5ed2c6e571201c28283c5e1d79eb8e2c5a9a3553157eccdba111afe2c44daf21\"","storePath":"irgfhhllbyq377yax32f0kfkidkgic12-master.tar.gz","url":"https://codeload.github.com/<user-name>/foo/tar.gz/refs/heads/master"}'
performing daemon worker op: 11
acquiring write lock on '/nix/var/nix/temproots/3148506'
performing daemon worker op: 1
using cache entry 'file:{"name":"master.tar.gz","store":"/nix/store","url":"https://github.com/<user-name>/foo/archive/master.tar.gz"}' -> '{"etag":"W/\"5ed2c6e571201c28283c5e1d79eb8e2c5a9a3553157eccdba111afe2c44daf21\"","url":"https://codeload.github.com/<user-name>/foo/tar.gz/refs/heads/master"}', '/nix/store/irgfhhllbyq377yax32f0kfkidkgic12-master.tar.gz'
unpacking 1 channels...

And if I clear the cache manually

$ rm -rf ~/.cache/nix/fetcher-cache-v3.sqlite*
$ nix-channel --update
$ nix repl
$ builtins.readFile <foo/bar>
"2\n"

Expected behavior

nix-channel --update will not cache anything and always update.

Metadata

nix-env (Nix) 2.24.11

Additional context

Checklist

• checked latest Nix manual (source)
• checked open bug issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[eclairevoyant]

Do you see the same with --option tarball-ttl 0?

[Radvendii]

--option tarball-ttl 0 fixes the problem 👍

It still seems to me that --update should imply "don't cache".

[eclairevoyant]

It seems to me that the behaviour is as designed, see https://nix.dev/manual/nix/2.24/command-ref/conf-file#conf-tarball-ttl

Files fetched via NIX_PATH, fetchGit, fetchMercurial, fetchTarball, and fetchurl respect this TTL.

It's quite unusual to need to update a tarball immediately after a prior update, which is why the default is 6 hours. You can of course use nix.conf to set another value.

[Radvendii]

nix-channel --update is significantly different than all other uses of fetch*. Usually, there's something else that you're doing, and determining the tarball is a step in getting to the other outcome you want, so it makes sense to cache it, and it's something I would expect. In this case, All you're doing is determining the tarball. It's an update command. Why else would I be running it?

I also don't agree that it's so unusual. I can't speak from personal experience because I don't use nix channels very much (this came up in a professional context), but I can think of three cases that come up quite naturally:

1. I'm hacking on a repo I use via nix-channel.
2. I'm trying to debug an issue with nix channels themselves
3. Someone using my channel encounters a bug, runs nix-channel --update, but it doesn't fix the bug. They raise an issue, I fix the problem in less than 6 hours and ping them back. They run nix-channel --update again and it doesn't solve anything.

Setting tarball-ttl 0 in nix.conf is not a satisfactory solution since it disables all tarball caching, which is a useful feature.

[Radvendii]

It's like if nix flake update didn't update an input because it had already updated that input in the last 6 hours.

[eclairevoyant]

Correcting myself: it's one hour, not six.

It's like if nix flake update didn't update an input because it had already updated that input in the last 6 hours.

Yes, nix flake update also respects tarball-ttl.

[Radvendii]

Yes, nix flake update also respects tarball-ttl.

😮 Does this apply to github:foo/bar inputs?

Do you understand my argument though? Maybe from an implementation standpoint this makes sense, but from the perspective of a user, the purpose of nix-channel --update and nix flake update is not to fetch the tarball. It's to update the reference to the tarball. Hitting a cache just no-ops. So why would I be running the command?