Files
ottyl/tickets/016-filter-by-json-field.md
T
Hugh KaznowskiandClaude Sonnet 5 b1e509efbd Record JSON log ingestion design decision, file follow-up tickets (ticket 003)
Decision covers detection, invalid-JSON handling, and a prioritized feature
roadmap (repowise decision fdb47034ad954e3ea0b898fdc2750c32). Files three
follow-up implementation tickets (014-016) and removes the investigation
ticket now that the decision is recorded.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XFUNZwCvz3kcod3352ZR2o
2026-09-05 18:36:27 +01:00

916 B

Support filtering/querying by JSON field in the filter bar

Follow-up to the JSON log ingestion design decision (repowise decision fdb47034ad954e3ea0b898fdc2750c32).

Extend the filter query language with a JSON field accessor (e.g. json[field] <op> value), comparable to the existing metric[param] <op> value comparison, so JSON fields can be filtered without first declaring a metric/param for them.

Acceptance criteria

  • filter_parser.pest gains a json[field] (or similar) accessor usable anywhere metric[param] is today, for comparisons.
  • The engine evaluates json[field] against a line's parsed JSON (when it parses as an object), consistent with how declared params/metrics are evaluated today.
  • Lines that aren't valid JSON simply don't match any json[field] comparison (no error).
  • Existing filter syntax (metric/param comparisons, regex(), sequence, timestamp, and/or) is unaffected.