Working with Signals

SignalFilterPart

Signals are composed of SignalFilterParts.

Filter vs FilterNonStrict

Seq provides a facility for attempting to parse free text as filters, so you can write queries that look like Contains(@Exception, "invalid"), i.e. that are fully-formed expressions, or you can just type invalid into the filter box and Seq will treat the whole thing as text to search for.

(There's an example of this being used via the API here: https://github.com/continuousit/seq-api/blob/master/example/SeqTail/Program.cs#L78.)

Now, the catch with this is stability over time. Today, one might write a filter select count(*) and since Seq doesn't support select syntax, it'll be interpreted as text to search for. If this is saved in a signal, then you might find events containing SQL statements. However, in a future release Seq may get aggregate queries, so select count(*) might suddenly become valid query syntax. If the signal were only based on the text the user entered, then the meaning of the signal would change and all would be chaos.

So, Filter contains a backwards-compatible internal representation of the expression, for use by the server, and FilterNonStrict contains the text that the user actually typed, so that it can be displayed or manipulated by the UI.