allowedUnmatched not working as expected.

[hartsock]

We have an unusual bug in our buildfarm deploy. Some product-teams send us "OSFamily" and "Linux" and this does NOT match "OSFamily" and "Linux" in the queue configuration used by servers or workers.

Examples:

  queues:
    - name: "*"
      allowUnmatched: true
    - name: "default"
      allowUnmatched: true
      properties:
        - name: "OSFamily"
          value: "*"
    - name: "linux"
      allowUnmatched: true
      properties:
        - name: "min-cores"
          value: "*"
        - name: "max-cores"
          value: "*"
        - name: "OSFamily"
          value: "Linux"

Even with all three queues defined, the client is seeing

(INVALID) The `Platform` of the `Command` was invalid.: properties are not valid for queue eligibility: [name: "OSFamily"
value: "Linux"
].

Conjectures:

• Is a hidden char in the "Linux" string is making it into an upstream OSS project's actions from the Bazel side of the conversation?
• Is a charset difference between the Bazel and BuildFarm service present and causing a mismatch?
• Is the character * used on the service/worker side configuration from a different alphabet than the one in the JDK?

Either way, rearranging the order of the checks produces the desired effect and the client no longer receives the error that "Linux" does not equal "Linux" ... still ... it would be nice to specify "Linux" and have it match "Linux"

Is this as intended? Should allowUnmatched: true refuse to match when the properties don't match?

[werkt]

I'll admit I'm not following a couple of things:
Minor: The invalid message string you pasted is missing some copy at the end, based on

bazel-buildfarm/src/main/java/build/buildfarm/instance/shard/ServerInstance.java

Line 1807 in f3f0cfd

"properties are not valid for queue eligibility: %s. If you think your queue"

. If you truncated it to be more brief, that's understandable.
Major: The error message above, which is the only instance of that copy, occurs on the server, not the worker, but your change only affects worker activity. I don't see how it could possibly cause the error to not occur based on where that error is generated.

The Command's definition is conveniently stored in a blob in this case which must be deserialized by the stock protobuf parser - if you can retrieve the Command's bytes (bf-cat File will retrieve this for the digest), parse those bytes into a Command message, and compare it to a config-parsed queue definition, we should be able to route out any differences due to encodings.

Happy to do that comparison myself if you want to present a pathological copy of your Command blob.