发布

  • [OPIK-6766] [FE] feat: restore operator choice on Logs string/ID filters (#6946)

    frostbyte_neo 发布于 2026-06-02 11:00:02 +00:00

    • [OPIK-6766] [FE] feat: restore operator choice on Logs string/ID filters

    Replaces the fixed-operator Pseudo-search chips on the Logs page
    (Traces / Spans / Threads) with query-builder chips so users can pick
    an operator again — restoring "does not contain" on text fields and
    "is empty / is not empty" on the annotation queue id (list) field that
    the chip rollout had dropped.

    • Convert Input/Output/Name/IDs/messages/annotation_queue_ids from
      pseudo-search to query-builder definitions (no key, value-only,
      multi-row AND-ed conditions).
    • Operator sets by BE-supported type:
      • STRING / STRING_EXACT: contains, not_contains, starts_with,
        ends_with, =, != (is_empty/is_not_empty are not BE-supported here)
      • LIST (annotation_queue_ids): contains, not_contains, =, !=,
        is_empty, is_not_empty
    • Add "!=" to FilterOperator + operator labels; add STRING_OPERATORS /
      LIST_OPERATORS constants.
    • Retire the pseudo-search chip kind: remove its definition/value
      types, switch cases (bar, manager, sanitize, compile, analytics),
      and delete chips/PseudoSearchChip.
    • Add z.literal("!=") to v1 + v2 automations FilterSchema (required by
      the FilterOperator union change).
    • Rework sanitizeFilters tests: text/ID fields now accept the full
      operator set instead of dropping all but contains/=.

    Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

    • fix(filter-chips): default ID filter chips to "contains"

    Per UX feedback: keep all operators, but ensure contains / does not
    contain lead the operator list and "contains" is the default. The
    text and list chips already defaulted to contains; the ID chips
    (Trace ID / Span ID / Thread ID) defaulted to "=" — switch them to
    "contains" for consistency.

    Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

    • fix(filter-chips): per-field add-condition label ("Add input")

    Per UX mock: the query-builder add button should read "Add {{filter_name}}"
    (e.g. "+ Add input"), not a generic "Add condition". Drop the addLabel
    override so each chip falls back to the framework default
    Add <label.toLowerCase()>.

    Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com


    Co-authored-by: Claude Opus 4.8 noreply@anthropic.com

    下载附件