[bug#44193] [PATCH 0/1] 'guix publish --cache' can publish items not yet cached

[Miguel Ángel Arruga Vivas]

Hi!

Just one general comment about this issue:

Ludovic Courtès <ludo@gnu.org> writes:
> Thus, the first narinfo request for an item would always return 404;
> one would have to wait until the item is baked to get 200 and download
> the substitute.

I'd argue that returning unconditionally the 404 is a problem.  If the
nar is getting baked, I guess that a 202[1] would be the appropriate
answer, and I'd leave the 404 for invalid store paths[2].  This way the
client could implement more policies: the classic timeout, but also, for
example, it might check other servers before checking once again if
nobody else has it, or directly wait until a 404 is reached.  WDYT?

Happy hacking!
Miguel

[1] Section 10.2.3 from https://www.ietf.org/rfc/rfc2616.txt
[2] I understand that it isn't at all a bad usage of the 404, as it
    explicitly says that the condition might be temporary, but on the
    other hand I don't know how could that extra information be used by
    a rogue client in any way worse than it could do right now, as the
    server process is doing the same computation more or less in both
    cases.