Do not copy for both stores for now

Ericson2314 · Ericson2314 · commit 2ee0068fdca7 · 2023-12-07T15:05:03.000-05:00
It has a performance cost, and as the comment says we should be doing
the better solution. We want to land this preparatory change on prod
while the rest is still on staging, so we should just skip it for now.

Skipping it will not affect regular fixed-output and input-addressed
derivations, which are the only ones prod would deal with upon getting
this code.

The main CA derivations support branch will revert this commit so it
still works.
diff --git a/src/hydra-queue-runner/build-remote.cc b/src/hydra-queue-runner/build-remote.cc
@@ -425,20 +425,6 @@ static void copyPathFromRemote(
     const ValidPathInfo & info
 )
 {
-    // Why both stores? @thufschmitt says:
-    //
-    // > I think it's an easy (and terribly inefficient 😬) way of
-    // making sure that `localStore.queryRealisations` will succeed
-    // (which we IIRC we need later to get back some metadata about the
-    // path to put it in the db).
-    // >
-    // > To be honest, we shouldn't do that but instead carry the needed
-    // metadata in memory until the point where we need it (but that can
-    // come later once we're confident that this is at least correct)
-    //
-    // TODO make the above change to avoid copying excess data back and
-    // forth.
-    for (auto * store : {&destStore, &localStore}) {
       /* Receive the NAR from the remote and add it to the
           destination store. Meanwhile, extract all the info from the
           NAR that getBuildOutput() needs. */
@@ -458,8 +444,7 @@ static void copyPathFromRemote(
           extractNarData(tee, localStore.printStorePath(info.path), narMembers);
       });
 
-      store->addToStore(info, *source2, NoRepair, NoCheckSigs);
-    }
+      destStore.addToStore(info, *source2, NoRepair, NoCheckSigs);
 }
 
 static void copyPathsFromRemote(
