Don't log an exception when there's a batch stat failure: it's not indicative of an underlying Bazel bug.
@@ -39,7 +39,6 @@ import com.google.devtools.build.lib.profiler.Profiler;
import com.google.devtools.build.lib.profiler.SilentCloseable;
import com.google.devtools.build.lib.skyframe.SkyValueDirtinessChecker.DirtyResult;
import com.google.devtools.build.lib.skyframe.TreeArtifactValue.ArchivedRepresentation;
-import com.google.devtools.build.lib.util.LoggingUtil;
import com.google.devtools.build.lib.util.Pair;
import com.google.devtools.build.lib.util.io.TimestampGranularityMonitor;
import com.google.devtools.build.lib.vfs.BatchStat;
@@ -69,7 +68,6 @@ import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.atomic.AtomicInteger;
-import java.util.logging.Level;
import javax.annotation.Nullable;
/**
@@ -320,9 +318,8 @@ public class FilesystemValueChecker {
/*includeLinks=*/ true,
Artifact.asPathFragments(artifacts));
} catch (IOException e) {
- // Batch stat did not work. Log an exception and fall back on system calls.
- LoggingUtil.logToRemote(Level.WARNING, "Unable to process batch stat", e);
- logger.atWarning().withCause(e).log("Unable to process batch stat");
+ logger.atWarning().withCause(e).log(
+ "Unable to process batch stat, falling back to individual stats");
outputStatJob(
dirtyKeys,
shard,
