tree dcd32ceb3625c94283ca1d9c5a160294688c6c7d
parent 858a4b1a44f1058f5bbec9ea778421038ef34f10
author janakr <janakr@google.com> 1583249548 -0800
committer Copybara-Service <copybara-worker@google.com> 1583249614 -0800

If a TreeFileArtifact is not explicitly in ActionExecutionValue's metadata map, check its TreeArtifactValue cache and return a value if it's there. Much of the time, a TreeFileArtifact's metadata will be in the main map: if it was the output of a templated action, it will be in the main map. It will also be there if it was explicitly statted/injected, either from Google-internal remote execution or as part of local execution.

However, if the tree artifact was injected via ActionMetadataHandler#injectRemoteDirectory, it is not present in the main metadata map.

I considered two other options for this CL:
(1) Explicitly add TreeFileArtifact metadata in ActionMetadataHandler#injectRemoteDirectory. Leads to increased memory usage for tree artifacts with Bazel remote execution (though just on parity with Google-internal/local) and maintains this as a sharp edge that could lead to crashes in the future if another use case is added.
(2) Explicitly add TreeFileArtifact metadata inside OutputStore#putTreeArtifactData. Duplicates work for local/Google-internal remote execution, where the metadata was already added, and has memory disadvantage.

This change seemed better: it makes explicit that TreeFileArtifacts don't have to be added, and saves a bit of memory at the cost of three map lookups instead of one for TreeFileArtifacts with Bazel remote execution. If Google-internal remote execution supported directories natively, we would move in this direction there as well.

PiperOrigin-RevId: 298601895