Making search more developer-friendly

When tuning the various Raygun subsystems, search is an important focus for us. The text, code and custom data featured in your Raygun error payloads presents unique challenges for both querying and indexing and we’re constantly thinking about how we can provide the best search experience for you.

A couple of recent changes that have been applied to the back-end will give you more exact results from the data attached to your exceptions. Here’s the details:

Exact string queries

The default behavior for your input query is to split it into tokens on CamelCase transitions, non-letter characters such as hyphens (‘wi-fi’ will be split into ‘wi’ and ‘fi’), letter-number transitions and finally by whitespace. It is also case-insensitive. This provides more inclusive results that increase the chance of returning your desired exception, at the cost of some noise. If you input a CamelCased query containing part of a class name, it will return exceptions of that class, yet those tokens may also match other exceptions with those tokens in custom data or request data, for instance.

To get more exact results, we now provide a better exact querying implementation. This is activated by wrapping your query in double-quotes, e.g

"Foo-Bar BarBaz"

This is only split by whitespace (note that it is still case-insensitive like the standard inexact query above). It will only return exceptions where the message contains the strings “foo-bar” and “barbaz”- an inexact query will also return exceptions that contain ‘foo’, ‘bar’ and ‘baz’ by themselves.

Note that a current limitation is that this only applies to errors which were received after October 10 so old errors will not be matched by exact queries at this stage.

Querying with common code operators

We automatically strip out parentheses as two matching brackets are really common in function/method calls (e.g. ‘foo();’). Parentheses (‘curvy brackets’) are a reserved character in our search stack (which uses the Lucene parser rules under the hood) so we sanitize them to reduce your mental workload. You can query for ‘foo()’ which will return all exceptions with it present, for instance in the stacktrace. There’s a limitation here that providing a method name with parameters will cause the query engine to group by the text inside the parentheses, which might not be quite the effect you wanted – the best option here is to simply drop the brackets.

This also applies to the C++ scope resolution operator, so you can query for ‘foo::bar’ which will return exceptions with that call in the stack trace. This avoids affecting our specific field prefixes (documented here under Search), which allow you to only search across a certain field such as the message or tags.

If you find other common operators in your language are getting in the way of the results you want, let us know and we’ll add them so they’re automatically sanitized.

Don’t have a Raygun account yet? Grab a free trial here, no credit-card needed, and experience professional-grade error tracking now.