Currently if you build a target that has resources (storyboards or asset catalogs in my testing) bazel will end up caching a file for the null sha e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. With remote caches this results in failed builds if you accept this file in your cache.

You can reproduce this with one of the sample projects in this repo:

bazel build //examples/ios/HelloWorld --disk_cache=cache
ls cache | grep e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Here you should see a match. If you remove all the resources portions of this BUILD file, this is no longer the case. After applying this diff:

diff --git i/examples/ios/HelloWorld/BUILD w/examples/ios/HelloWorld/BUILD
index 7f9385d..a3c4753 100644
--- i/examples/ios/HelloWorld/BUILD
+++ w/examples/ios/HelloWorld/BUILD
@@ -15,9 +15,6 @@ objc_library(
         "Sources/AppDelegate.m",
         "Sources/main.m",
     ],
-    resources = [
-        "Resources/Main.storyboard",
-    ],
 )
 
 apple_bundle_version(
@@ -27,14 +24,12 @@ apple_bundle_version(
 
 ios_application(
     name = "HelloWorld",
-    app_icons = ["//examples/resources:PhoneAppIcon.xcassets"],
     bundle_id = "com.example.hello-world",
     families = [
         "iphone",
         "ipad",
     ],
     infoplists = [":Info.plist"],
-    launch_storyboard = "//examples/resources:Launch.storyboard",
     minimum_os_version = "8.0",
     version = ":HelloWorldVersion",
     deps = [":Sources"],

And running:

rm -rf cache
bazel clean
bazel build //examples/ios/HelloWorld --disk_cache=cache
ls cache | grep e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

You should no longer see any matches. I see a few other references to e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 in other bazel issues, but none specifically talking about whether or not it is a problem. It seems like a few remote cache implementations work around this by not caching files that are empty (which seem to only happen for us when the key is also this sha). I can't find the exact rule that causes this with aquery, but I'd love to know if this is considered an issue, or if we should work around this in our remote cache.