[VibeSWE]

Summary

Ports upstream parseablehq/parseable@44bd8db7 ("feat: save promql queries in filters", parseablehq#1830). It was cherry-picked with -x, so the original author and commit are kept. The second commit adds tests and fixes the frontend.

Upstream change: adds FilterType::Promql (serialized as "promql"). list_filters now authorizes PromQL saved filters by their stream_name, the same way it handles Search and Filter, and the if/else became an exhaustive match. Before this, an unknown filter type was rejected on create (400 from serde). A type with no matching branch would also have been left out of the list silently.

Ramifications checked

• Authorization by dataset name is correct for PromQL in this fork. The PromQL API (src/handlers/http/promql.rs) needs exactly one dataset from X-P-Stream or stream, and it authorizes only that dataset. A PromQL query cannot reach metrics in other datasets, so authorizing the saved filter's stream_name matches what running it would require. Authorizing the query text instead would be wrong: user_auth_for_query parses SQL table names, so a PromQL query would fail to parse and the filter would be hidden from everyone.
• stream_name is always set. It is a required String on Filter. validate_stream_name checks it as a user-defined dataset name on POST/PUT, so the sql sentinel, empty names and path-like names are rejected for PromQL. There is a test for this.
• Every other FilterType use (metastore canonicalization and alias cleanup, preserve_filter_identity, convert_filter_to_sql) only special-cases SQL. PromQL is handled like Search/Filter, and convert-to-sql rejects it. The tool catalog (list_filters / get_filter) goes through the same handlers and needs no change.
• Mixed versions / rollback: when loading from the metastore, records that fail to deserialize are skipped (let Ok(..) else { continue }). A node without this change just ignores PromQL filters and still loads the rest.
• Frontend bug (fixed here): savedLogView only accepted filter|sql|search, and listLogViews rejects the whole /filters response if any entry fails. One saved PromQL filter would have broken Saved log views and the SQL sidebar's server queries for every user who can see it. Now promql is accepted, and PromQL filters are kept out of the Logs saved-view picker, which would otherwise have listed them as "classic" views of their dataset. The SQL sidebar already ignores non-sql filters.

Tests

• Rust: PromQL serde round-trip. list_filters returns a PromQL filter to a session with query access and hides it from one with none. A mutation check confirmed this test fails if PromQL goes through the SQL path. Also tests for PromQL stream_name validation and convert-to-sql rejecting PromQL.
• Frontend: the list contract accepts a mix of SQL and PromQL entries, PromQL is excluded from Logs saved views, and it is ignored by server saved SQL queries.

Ran: cargo fmt --check, cargo clippy --all-targets (exit 0; the remaining warnings are all in files this PR doesn't touch), cargo test (849 lib tests passed, plus integration tests) with P_BUILD_NO_UI=1. Frontend: npm run format:check, tsc --noEmit, vitest run src (2415 passed).

Follow-ups (not in this PR)

• Save and open PromQL queries as views in the Metrics explorer. The backend supports it now. The UI needs a saved-view dialog (create, update, delete, ownership) and a decision on what to save, since the explorer state holds several queries plus a step and range. That's more than a small change, so it is left out of this PR.
• GET /filters/{id} (get_internal) checks ownership or admin but not dataset access, for every filter type. This was already the case before this PR.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}