-
[OPIK-4416] [BE] fix: separate dedup from custom sorting in span/trace queries (#5679)
frostbyte_neo 发布于
2026-03-17 14:40:48 +00:00 - [OPIK-4416] [BE] fix: separate dedup from custom sorting in span/trace queries
ClickHouse ReplacingMergeTree tables may have unmerged duplicate rows.
When sorting by a custom field (e.g. usage.total_tokens), the LIMIT 1 BY
deduplication picked whichever row version ranked highest in the custom
sort order, not the latest version by last_updated_at. This caused stale
row data to appear in the UI when sorting.Fix: split the query into two CTEs — first deduplicate with the default
ORDER BY (which includes last_updated_at DESC), then sort and paginate
the clean data by the user's requested field.Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
- fix(sorting): add last_updated_at DESC tiebreaker to custom sort ORDER BY
Ensures deterministic pagination when custom sort field values are equal
across rows, consistent with the default (non-sorted) ORDER BY branches.Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
- fix(sorting): always append base ORDER BY instead of duplicating branches
Address PR review feedback: instead of separate if/else ORDER BY branches,
always prepend custom sort fields before the consistent base sort tuple.Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
- test(traces): add regression test for sorting with stale row dedup
Equivalent of the span regression test for TraceDAO: creates a trace,
updates it with different name/input, sorts by name DESC, and asserts
the latest version is returned.Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.6 (1M context) noreply@anthropic.com
下载附件