bug#70588: hash mismatch error and stop fallback

[Simon Tournier]

Hi,

On lun., 02 oct. 2017 at 17:09, ludo@gnu.org (Ludovic Courtès) wrote:

> The problem is that the hash check is performed by guix-daemon itself,
> not by “guix perform-download”.  So when guix-daemon diagnoses a hash
> mismatch, it’s too late and we cannot try again and use the
> content-addressed mirror.

This quote from [1].  Well, why not run a sequence of “guix download”
then “guix build”?  Ah the store item would be hashed twice.  Let try to
avoid this sub-optimized behaviour.

The only way to avoid hashing twice is to extend the protocol of
guix-daemon.  Because currently it reads,

            /* Check the hash. */
            Hash h2 = recursive ? hashPath(ht, actualPath).first : hashFile(ht, 
actualPath);
            if (h != h2) {
                if (settings.printBuildTrace)
                    printMsg(lvlError, format("@ hash-mismatch %1% %2% %3% %4%")
                             % path % i->second.hashAlgo
                             % printHash16or32(h) % printHash16or32(h2));
                throw BuildError(format("hash mismatch for store item '%1%'") % 
path);
            }

with the call under error catch:

        /* Compute the FS closure of the outputs and register them as
           being valid. */
        registerOutputs();

[...]

    } catch (BuildError & e) {


Thus the number of solutions is very limited. :-)

Well, from my understanding, moving elsewhere in guix-daemon the check
of the hash appears to me too cumbersome.  Therefore, the only way is to
replace this ’BuildError’ by something that is not an error and do not
register the item.

Easier to say than to implement.  Again from my understanding, each
strategy for downloading is seen by the daemon as an element of a list
of independent builds and these elements are tried in sequence.
Therefore, we need to special case in order to be able to distinguish
different kind of failures.

All in all, this bug (missing feature):

        Other said, hash mismatch should be raised and obviously the content
        must be discarded; then the hash mismatch should be considered as “not
        found” so let try the next strategy for downloading the content.

is not straightforward to fix. :-)  Need for more thought…


Cheers,
simon


1: bug#28659: v0.13: guix pull fails; libgit2-0.26.0 and 0.25.1 content hashes 
fail
ludo@gnu.org (Ludovic Courtès)
Mon, 02 Oct 2017 17:09:39 +0200
id:87o9ppoabw.fsf@gnu.org
https://issues.guix.gnu.org/28659
https://issues.guix.gnu.org/msgid/87o9ppoabw.fsf@gnu.org
https://yhetil.org/guix/87o9ppoabw.fsf@gnu.org