Hi,
we are trying to improve our queries to search for workflows by certain custom search attributes by adding also a wildcard search. We followed the documentation about the List Filter and our expectation was that we can use the queries like following (from the docs - advanced visibility is enabled):
// Create a "ProductId" custom Search Attribute of type String
tctl admin cluster add-search-attributes --name ProductId --type String
// Match values that start with "book"
ProductId LIKE "book%"
// Match values that contain "favorite"
ProductId LIKE "%favorite%"
Now we have a custom search attribute StatusText that is of type Text . The values can be for example something like waiting for user , waiting for payment , payment received or payment declined .
However, the queries are not returning the expected result (using tctl workflow list -q )
StatusText LIKE "waiting for user" // result: all workflows with StatusText "waiting for user" = what we expectation
StatusText LIKE "waiting%" // result: nothing - expectation: values starting with "waiting"
StatusText LIKE "waiting" // result: returns all workflows containing "waiting" - expectation: no results (exact match)
StatusText LIKE "waiting payment" // result: returns all workflows containing "waiting" and "payment" ("waiting for user", "waiting for payment", "payment received", "payment declined") - expectation: no results
StatusText LIKE "waiting%payment" // result: nothing - expectation: values containing "waiting" and "payment" -> "waiting for payment"
StatusText LIKE "waiting rubbish" // result: returns all workflows containing "waiting" - expectation: no results
StatusText LIKE "%payment%" // result: nothing - expectation: values containing "payment" ("waiting for payment", "payment received", "payment declined")
It doesn’t matter if we’re using % as a wildcard or * , they do not work as expected - and the LIKE operator matches all values that contain any of the given values. So we wonder what causes this behaviour and why it doesn’t work as described in the documentation. What are we doing wrong? Or are the results described above the expected behaviour?
(The behaviour is the same for running Temporal locally with the docker containers as well as in Temporal Cloud)
All the best,
Chris