github-featured / comet-ml--opik

发布

0 发布 8,340 Git 标签

RSS 订阅源
  • 2.0.56-5540 0d5b6c25e5
    比较

    [OPIK-6385] [FE] Pass thread time range to ThreadDetailsPanel traces query (#6949)

    frostbyte_neo 发布于 2026-06-02 14:00:31 +00:00

    • [OPIK-6385] [FE] Pass thread time range to ThreadDetailsPanel traces query

    When a user opens a thread in v2 ThreadDetailsPanel, useTracesList was
    fetching traces by thread_id without any time bounds. Since thread_id
    isn't part of the traces primary key (workspace_id, project_id, id),
    ClickHouse couldn't prune granules and had to scan the entire project,
    causing read timeouts on large datasets (e.g. ~4.7M traces in prod).

    This change passes the thread's start_time/end_time as fromTime/toTime to
    useTracesList. The backend converts those to UUIDv7 bounds on id, letting
    ClickHouse use the primary key to prune directly. Also gates the traces
    query on the thread being loaded so we never fire with undefined times.

    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

    • Revision 2: handle null/errored thread before traces loader guard

    The previous commit added Boolean(thread) to the useTracesList enabled
    gate so we wouldn't fire the traces query with undefined time bounds.
    However, with React Query v5, a disabled query with no cached data
    reports isPending=true (status='pending', fetchStatus='idle'). The
    outer renderContent guard was if (isThreadPending || isTracesPending) return <Loader /> which means when the thread query resolves with no
    data (404, error, deleted thread), isThreadPending=false but
    isTracesPending stays true forever — making the panel stuck on the
    loader and the !thread → NoData branch unreachable.

    Remove isTracesPending from the outer guard. The inner renderBody
    already shows its own Loader for the traces table, so this check was
    redundant in the happy path and harmful in the failure path. This also
    matches v1's pattern (v1 uses && for the analogous guard for the
    same reason).

    Verified live in the browser:

    • State #4 (URL with nonexistent thread_id) → panel renders NoData,
      not stuck spinner
    • State #3 (verify-bulk-thread happy path) → panel renders with all
      10 trace messages; original PR fix intact (from_time/to_time still
      in the trace request URL)
    • State #2 (regular thread-N with ~5000 traces) → panel renders with
      full chrome and 1000 trace rows, no stuck loader

    Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

    Co-authored-by: Claude Opus 4.7 (1M context) noreply@anthropic.com

    下载附件