feat: quick filter button

[msmithstubbs]

Adds a quick filter button the event viewer.

• quick filter appends a FilterRule to the LQL query string of the current search.
• the button is only displayed if the value is less than 500 characters
• array values will use the list includes search operator
• timestamp field the search will be +/- 1 of the current chart duration (eg. +1 hour and -1 hour).

The quick filter button is implemented as slot passed to the JSON view component. We could easily add more actions to the UI (even user configurable ones).

Todo

• let's shrink the icon more
• let's only show the icon on hover, we can always show icon for the event message and timestamp fields.
• we should use the same tailing behaviour all the time even if it is a timestamp field,
• extract the lql manipulation logic to Lql.Rules
• use lql_schema from parent liveview in QueryComponents
• source_schema_flat_map in liveview

Demo

CleanShot.2026-02-04.at.15.32.10.mp4

[Ziinc]

Hmm I'm of the opinion we should use the same tailing behaviour all the time even if it is a timestamp field, since this implies zooming in on historical data

[msmithstubbs]

we should use the same tailing behaviour all the time even if it is a timestamp field

I've removed the special case so tailing will be preserved from the current liveview state.
Is that how you wanted it to work?

[Ziinc]

Yea only want to trigger tailing on first view of the search page, other flows don't really make sense for the associated cost.

[Ziinc]

We can extract the lql manipulation logic to Lql.Rules,not the first time we're doing such rule manipulation

[msmithstubbs]

I switched this to use Rules.upsert_filter_rule_by_path

logflare/lib/logflare/lql/rules.ex

Line 253 in b764c03

def upsert_filter_rule_by_path(lql_rules, %FilterRule{path: path} = filter_rule)

This will append the rule if doesn't exist, or replace if it does, which I think is the correct behaviour. I don't think we'd want the quick filter action to create a search with two rules ( m.qty:12 m.qty:11 for example) since that wouldn't return any results.

[Ziinc]

The parent liveview should have this already

[Ziinc]

From my recollection, stored source schema flatmaps do not store the array index, could you double check the behaviour?
It would only store the inner types and not an individual key per index.

[msmithstubbs]

That's correct, the array index key was coming from the JSON viewer component. I used the array index as a key when rendering arrays.

I've updated the JSON component so it doesn't pass the array index as a key anymore.
This means a little more duplicate in the JSON component, but less logic in QueryComponents.

[Ziinc]

I see. There could be edge case bugs where stringified numbers are used for field keys and the walk up will skip that level, could you check 🙏
Walk up logic is fine to keep though

[msmithstubbs]

There could be edge case bugs where stringified numbers are used for field keys

It's a good point. I thought I'd handled that but it didn't work if the numeric key was in the middle of the field (metadata.0.info).

I'm sticking with passing the full path through from the view component. This should match the field name used in the schema flat map.

[msmithstubbs]

Added test coverage, too.

[Ziinc]

Styling wise:

• let's shrink the icon more
• let's only show the icon on hover, we can always show icon for the event message and timestamp fields.