Skip to content

Unify saved-query and Dashboard time-range inference #391

Description

@BorisTyshkevich

Context

While implementing #334 / PR #390, the Dashboard filter bar appeared to regress to separate From and To fields for existing saved queries. There is only one filter-panel renderer; the visual regression happened because two paths decide whether a compound time-range group exists:

  • save-time inference persists spec.timeRanges during saved-query create/commit;
  • load-time inference is still required for legacy saved queries that predate that metadata.

Removing the second path breaks existing dashboards. Keeping both as independent implementations risks drift in ambiguity handling, supported parameter types, targeting, diagnostics, and explicit opt-out behavior.

Desired outcome

Provide one shared inference policy/result model that both save-time metadata persistence and legacy Dashboard load-time compatibility consume, without coupling the Dashboard UI to SQL parsing or persistence.

Required semantics

  • Omitted timeRanges on a legacy saved query may use conservative load-time inference.
  • Explicit timeRanges: [] is authoritative opt-out and must never fall back to inference.
  • A non-empty authored value is authoritative; malformed or unresolved authored metadata fails closed with diagnostics.
  • Inference remains exact-name, ambiguity-safe, target-aware, scalar-only, and limited to supported date/time contracts.
  • Existing dashboards retain the Dashboard time-range control: token-based From/To picker in the filter bar #335 compound control without requiring users to edit and re-save every query.
  • The filter bar continues to have a single rendering implementation.

Acceptance criteria

  • Shared tests define identical pair inference semantics for save-time and load-time callers.
  • No duplicated name-pair table or divergent ambiguity/type gates.
  • Mixed dashboards with legacy, opted-out, and authored queries resolve deterministic tile membership.
  • DOM regression coverage proves legacy metadata omission still produces one compound control and suppresses the individual bound fields.

Discovered during #334 implementation and compatibility repair in PR #390.

Metadata

Metadata

Assignees

No one assigned

    Labels

    inboxFiled mid-task; not yet triaged into the roadmap

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions