lib/path: allow CA paths in hasStorePathPrefix (#386774)

lib/path/default.nix

···
     # but this is not fully specified, so let's tie this too much to the currently implemented concept of store paths.
     # Similar reasoning applies to the validity of the name part.
     # We care more about discerning store path-ness on realistic values. Making it airtight would be fragile and slow.
-    && match ".{32}-.+" (elemAt components storeDirLength) != null;
+    && match ".{32}-.+" (elemAt components storeDirLength) != null
+    # alternatively match content‐addressed derivations, which _currently_ do
+    # not have a store directory prefix.
+    # This is a workaround for https://github.com/NixOS/nix/issues/12361 which
+    # was needed during the experimental phase of ca-derivations and should be
+    # removed once the issue has been resolved.
+    || match "[0-9a-z]{52}" (head components) != null;
 
 in
 # No rec! Add dependencies on this file at the top.

lib/path/tests/unit.nix

···
       expected = true;
     };
 
+    # Test paths for content‐addressed derivations
+    testHasStorePathPrefixExample7 = {
+      expr = hasStorePathPrefix (/. + "/1121rp0gvr1qya7hvy925g5kjwg66acz6sn1ra1hca09f1z5dsab");
+      expected = true;
+    };
+    testHasStorePathPrefixExample8 = {
+      expr = hasStorePathPrefix (/. + "/1121rp0gvr1qya7hvy925g5kjwg66acz6sn1ra1hca09f1z5dsab/foo/bar");
+      expected = true;
+    };
+
     # Test examples from the lib.path.subpath.isValid documentation
     testSubpathIsValidExample1 = {
       expr = subpath.isValid null;