What recent change to Firestore makes it complain about "Overlapping recursive wildcard match statement"?

Question

Today I noticed that I am unable to deploy my Firestore rules, even though they worked fine until now and I didn't change them. Here's an excerpt of the part it doesn't like:

match /databases/{database}/documents {

    function userMatchesId(userId) {
      return request.auth != null
          && request.auth.uid == userId
    }

    function userIsAdmin() {
      return request.auth != null
          && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "admin"
    }

    // === Admins ====
    // Admin users are allowed to access everythings.
    // Writes should be performed via code executed by a service account
    match /{document=**} {
      allow read: if userIsAdmin()
    }

    // ==== Private ====
    // Collections private to the user. Documents read access is matched
    // with the authenticated user id.
    match /users/{userId} {
      allow get: if userMatchesId(userId)
    }

    match /userCredits/{userId} {
      allow get: if userMatchesId(userId)
    }
}

In practice these rules have worked as I imagined it. Admins are allowed to read from collections that non-admins are not able to query directly. However, now I get this error during deployment:

Error: Compilation error in firestore.rules:

[W] 42:5 - Overlapping recursive wildcard match statement.

I do not quite understand the issue here. How would you fix this?

Answer 1

(Googler here) This is a mistake on our part. We are adding new compiler warnings to rules that help you notice bugs you may be introducing. Many people don't realize that if you have more than one match statement that matches a particular path, then the rules from those blocks are OR'ed together. This warning was supposed to help you discover that.

However it was never intended for this to stop you from deploying valid rules if you understand what you're doing! We will fix this.

---

Update 8/1 @ 11:50am PST

We are making two changes here:

• We are releasing the CLI (npm firebase-tools) at version 4.0.2 with a fix for this issue to make warnings non-fatal. This should happen momentarily.
• We are going to change the server behavior to undo/clarify this behavior until we get it right.

Answer 2

You can get more information if you paste your rules in the firebase console...

You can see the error in the picture:

I had the same problem in my storage rules... when you remove wildcard match or all other matches without the wildcard, error goes away... But still trying to find a document from google to understand this change...

Update: After investigating further I noticed this problem is occurring in all rules (db and storage rules). I tried firebase's own example for wildcards from this link:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

Well, rules validator is failing for firebase's own example as well...

so this is either a new feature that's not documented or a bug.