From b1e509efbdb1cde847ee57a4d3861e96def8c600 Mon Sep 17 00:00:00 2001 From: Hugh Kaznowski Date: Sat, 5 Sep 2026 18:36:27 +0100 Subject: [PATCH] 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 Claude-Session: https://claude.ai/code/session_01XFUNZwCvz3kcod3352ZR2o --- tickets/003-json-log-ingestion-support.md | 13 ------------- tickets/014-json-log-structured-display.md | 10 ++++++++++ tickets/015-json-field-param-metric-declaration.md | 10 ++++++++++ tickets/016-filter-by-json-field.md | 11 +++++++++++ 4 files changed, 31 insertions(+), 13 deletions(-) delete mode 100644 tickets/003-json-log-ingestion-support.md create mode 100644 tickets/014-json-log-structured-display.md create mode 100644 tickets/015-json-field-param-metric-declaration.md create mode 100644 tickets/016-filter-by-json-field.md diff --git a/tickets/003-json-log-ingestion-support.md b/tickets/003-json-log-ingestion-support.md deleted file mode 100644 index fbcb84c..0000000 --- a/tickets/003-json-log-ingestion-support.md +++ /dev/null @@ -1,13 +0,0 @@ -# Investigate and design JSON log input handling - -Figure out what should and can happen if the logs are JSON input. What happens if the JSON is invalid during ingestion. What useful functionality can we have. - -## Notes -This is an investigation/design ticket before implementation. Needs a decision on: -- How JSON-formatted log lines are detected and parsed. -- What happens on invalid/malformed JSON during ingestion (drop, store raw, flag, error metric, etc). -- What functionality JSON structure could unlock (field extraction, filtering/querying by field, structured display in the log viewer, etc). - -## Acceptance criteria -- A short design decision is written (e.g. via `repowise decision add`) covering: detection, invalid-JSON handling, and prioritized feature ideas. -- Follow-up implementation ticket(s) filed based on the decision. diff --git a/tickets/014-json-log-structured-display.md b/tickets/014-json-log-structured-display.md new file mode 100644 index 0000000..c0dde72 --- /dev/null +++ b/tickets/014-json-log-structured-display.md @@ -0,0 +1,10 @@ +# Render JSON log lines as structured key/value trees + +Follow-up to the JSON log ingestion design decision (repowise decision fdb47034ad954e3ea0b898fdc2750c32). + +When an ingested log line's raw text parses as a JSON object, display it in the log viewer as a collapsible key/value tree instead of a raw string. Lines that aren't valid JSON objects keep rendering as plain text, unchanged. + +## Acceptance criteria +- LogPreview.tsx detects a JSON-object log line (starts with `{` and parses) and renders it as a collapsible key/value tree. +- Non-JSON (or invalid-JSON) lines are unaffected — same raw-text rendering as today. +- Detection/parsing happens client-side against the existing raw `text` field; no backend API change required for this ticket. diff --git a/tickets/015-json-field-param-metric-declaration.md b/tickets/015-json-field-param-metric-declaration.md new file mode 100644 index 0000000..d74edbf --- /dev/null +++ b/tickets/015-json-field-param-metric-declaration.md @@ -0,0 +1,10 @@ +# Allow params/metrics to be declared from a JSON field path + +Follow-up to the JSON log ingestion design decision (repowise decision fdb47034ad954e3ea0b898fdc2750c32). + +Extend param/metric declaration so a param can be extracted from a JSON field path (e.g. `foo.bar`) on lines that parse as JSON objects, as an alternative to the existing regex-capture-group extraction. + +## Acceptance criteria +- `RegexToMetricPrimitiveMatcher` (src/data_value.rs) or a sibling type supports a JSON-field-path extraction source alongside the existing regex-capture-group source, reusing `ParamRole`/`MetricPrimitiveKind`. +- The params declaration UI (Params.tsx) lets a user choose "JSON field" as an alternative to "regex capture group" when declaring a param, for lines detected as JSON. +- Existing regex-based params/metrics are unaffected. diff --git a/tickets/016-filter-by-json-field.md b/tickets/016-filter-by-json-field.md new file mode 100644 index 0000000..fc9be16 --- /dev/null +++ b/tickets/016-filter-by-json-field.md @@ -0,0 +1,11 @@ +# 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] value`), comparable to the existing `metric[param] 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.