Adjusting for the specifc hashes used in the example, I expect it to say
hash mismatch in fixed-output derivation '/nix/store/hhvgs3wwribfvkgdff7pmfnb4vy801bs-channel-rust-nightly.toml.drv': specified: sha256-hTj47PwUeP276uF6+HLDzsHYoDvfJa+y9o+vmxZqV0Y= got: sha256-hTj47PwUeP276uF6+HLDzsHYoDvfJa+y9o+vmxZqV0g=… which is exactly what it says in identical situations in a slightly different context … and I still haven’t got to the bottom of what exactly the context change is which turns the message from spot-on to almost useless.
When a thing exists upstream, but has different hash than expected, that’s what is reported. When it doesn’t and returns 404. the 404 status is reported. Of course, when the hash differs it is easy to say what is the current hash, and if the thing is missing completely, it is pretty hard to say where it could be found instead.
If you can suggest a better solution to this problem, I’d be most grateful.
Above Jan correctly tells you to just drop the date parameter (which does effectively the same thing but in a reasonable way and without abusing the way the server works).