bug#46212: ci.guix.gnu.org narinfos with excessive NarSize

[Ludovic Courtès]

Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

> This is what I get for the last one:
>
> sqlite> select * from validpaths where path = 
> '/gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5';
> 48732920|/gnu/store/q6qa5s2z2l20q25qpxyfv1wni5wwhk24-flightgear-2018.3.5|sha256:86426115e1f49835a24612ae89a180e87ac835332b4e83d19ecbd43211336cd2|1623360391|/gnu/store/722yyaa1qvkaakn6p7ywwr4dnm5wmddz-flightgear-2018.3.5.drv|-1610199336
>
>
> The registration date is:
>
> scheme@(guile-user)> ,use(srfi srfi-19)
> scheme@(guile-user)> (date->string (time-utc->date (make-time time-utc 0 
> 1623360391)) "~1" )
> $164 = "2021-06-10"
>
>> I think there were safeguards put in place to avoid bad data making it's
>> way in to the store database?
>
> I thought so too (commit 13a7d2a538b00aa0a8cf9b999f1a4ff3e5959af9)!
> So we must be using another code path.

At last I found the culprit (me! :-)).  This is fixed by commit
f9b1bb916c284bea00dd5549a43e0894b219d650.

The reason ci.guix would experience it and not bayfront is because the
Cuirass worker mechanism relies on substitutes to retrieve files from a
worker, and this is how it would end up storing a negative size.

We’ll have to upgrade the ‘guix’ package and deploy it on berlin.  I
don’t think it’s easily feasible to fix existing entries in the store
database and (more importantly) narinfos so I’d just leave them around;
the bogus nar size propagates but it’s harmless and doesn’t prevent
substitution.

Thoughts?

Ludo’.