buck2

This fixes https://github.com/facebook/starlark-rust/issues/120. Since it allows users now to compare records from different files.

Remote CAS loss could leave deferred builds unable to recover generated inputs or final outputs without a daemon restart. This matters because the build graph still contains producer actions that can recreate those blobs, but Buck was not always turning missing-CAS errors into graph rewinds. This is the Buck2 equivalent of Bazel's action-rewinding path. Bazel added in bazelbuild/bazel#25477, distinguishing single-build action rewinding from build-level retries via . That Bazel work also called out concurrency-sensitive cases around arbitrary values and async cache uploads through . This change tracks lost inputs as a typed batch so the build command can dirty all producer BuildKey nodes and the consumer in one rewind. Canonicalize rewind keys through the registered action lookup before dirtying DICE. This makes dynamic_output redirects invalidate the producer action that can recreate the missing blob. When a rewound action is replayed, bypass both Buck action-cache lookups and the remote executor cache lookup. Remote execution can otherwise return the same cached ActionResult, leaving the missing CAS blob absent and causing the consumer to hit the rewind cap. When local materialization discovers an expired CAS entry, convert the materializer not-found error into the same typed context. Also treat default final materialization not-found errors as rewindable, since materializations = deferred still materializes requested outputs unless the stricter skip-final mode is selected. When final materialization and final upload run together, upload can report a missing CAS blob before materialization cleans the shared queue. Because those branches run under try_compute2, the upload error can drop the materialization side before it removes queue_tracker entries. Clear those entries on the upload-side rewind path as well. Also clear the per-transaction materialization queue after committing a rewind, so the retry does not skip outputs that were queued before the DICE transaction was invalidated. The first version of this fix was developed and exercised against BuildBuddy remote execution. For upstream, the tests were rewritten to use Meta's remote-execution test hooks and a hybrid execution platform instead of depending on external RE configuration. They cover remote generated inputs, directory leaves, worker-side missing input reports, local-only consumers, default final materialization, final upload with materialization, and a missing-input count above the repeated-rewind cap. References: https://github.com/bazelbuild/bazel/pull/25477 https://github.com/bazelbuild/bazel/pull/25396 https://github.com/bazelbuild/bazel/pull/25412

By default Buck2 does not print the output of successful commands. The CLI offers some knobs to control this behavior: E.g. or will display stderr output of build commands even if they were succesful. However, there does not seem to be a way to access the stdout output of build commands that completed successfully. Even the following log query will not include stdout output of successful commands: This was confirmed with a build action that invoked a Python wrapper script by adding a command to the beginning of the Python script's main function. If the script is forced to fail by adding , then the stdout output is displayed by Buck2. This was observed on regular local build actions. However, relatedly I noticed that the persistent worker protocol does not provide a field to communicate stdout output from the worker to Buck2. To support stdout output of commands executed by a persistent worker would require extending that protocol.