The asterisk character is not matching all characters when doing a search, is this a bug?

[rsimmons]

The asterisk character is not matching all characters.

A search for :

rectype="bl*query"

returns 0 matching events

BUT

rectype="bl_*_query"

matches 700 as it should

However a search for:

rec=d*s

matches as many results as

rec=dns

Update from user stephenclough:

As the originator of this question, I want specify a little further what the search was intended to do.

the "rectype" field in this data sample has potential values of "bl_left_query", "bl_right_query", "bl_down_query" among others.

I add the context to 1)make more sense of the query that works (rectype="bl_*_query") and 2) show that I'm intending the * wildcard to match more than just a single character as might be suggested by the "rec=dns" search I mentioned.

-THanks for any answers!

[Stephen_Sorkin · Accepted solution]

The issue here isn't that `*` doesn't match more than one character, it does. The issue is that `*` doesn't match across what we call `breaking` characters, or the characters that break the raw string into segments (typically non-alphanumeric characters).

For efficiency, a search for `rectype="bl*query"` is going to ask the index for individual terms that start with `bl` and end with `query`, but `bl_12:3_query` looks like `bl`, `12`, `3` and `query` in the index.

Depending on your needs, we can change index time segmentation, but this is rarely a good idea. If you know where the breaking characters are in your string, we can change your search. Alternately, to get the behavior you're looking for you can search for `rectype="bl*" AND rectype="*query"`, since both `bl*` and `*query` are satisfied by the index.

We can also consider an enhancement request to support cross-breaker wildcards, but that comes at the detriment of performance.

[blurblebot]

UPDATE: It's a bug still in 4.1

I opened the case yesterday and received this answer last night:

..."However I did find out that this is a known documented bug that development is currently aware of. It has currently been escalated and we should have have a fix in a near release"

The version is 4.1, and the raw event did not contain an asterisk.

Cheers

[steveyz]

what version is this? There was a bug with asterisk searches that was fixed in 4.1, although that particular bug should only have affected cases where the raw event text also contained asterisks.

[gkanapathy]

that is, I see the same behavior as the original poster, without any asterisks in my raw text.

[gkanapathy]

I don't know what version the original poster is using, but I see the same behavior on 4.0.9.