69 lines
3.4 KiB
Markdown
69 lines
3.4 KiB
Markdown
# 074 — Timeline sort-by-property still doesn't work after tickets 059-061
|
|
|
|
## Summary
|
|
|
|
Wishlist feedback, verbatim: "The sorting on the timeline still does
|
|
not work. I have tried sorting things that I know are sorted (logs
|
|
param timestamp) and things that arent (thread name or pid). It does
|
|
not work (change view, index etc). If it's taking time to index, that
|
|
needs to be visible."
|
|
|
|
This is a regression/bug report against functionality that should
|
|
already exist: sort-by-param was added in ticket 045, and tickets
|
|
060/061 (resolved in commit `de9ba6f`, "Resolve tickets 059-061:
|
|
generic log-stream columns + sort helper indexes") replaced the naive
|
|
full-materialize-then-sort with an incremental helper-index scheme
|
|
(`SortHelperIndexEntry`, `build_sort_helper_index`,
|
|
`update_sort_helper_indexes`, `purge_stale_sort_helper_indexes` in
|
|
`engine.rs:1332-1431`), wired into the `EngineQuery::Logs` sorted
|
|
branch around `engine.rs:1598-1634`. On the frontend, `sortBy`/
|
|
`sortMissingFallback` are threaded from `LogTimeline.tsx`'s settings
|
|
through `App.tsx` (`:349-350`, `:505-506`) into `fetchLogs`
|
|
(`webapp/src/lib/api.ts:256-266`). Nothing found in a static read of
|
|
this wiring looks obviously broken, so this needs live reproduction,
|
|
not just a code read — treat the below as an investigation, not an
|
|
assumed root cause.
|
|
|
|
## Scope
|
|
|
|
- Reproduce with `make dev` against real piped input: declare a param
|
|
covering thread name or PID, set the timeline's sort dropdown to it,
|
|
and confirm whether results actually reorder. Also test sorting by an
|
|
already-monotonic value (`ottyl_ts` or a declared timestamp param) to
|
|
isolate whether the bug is "sort does nothing" vs. "sort scrambles an
|
|
already-correct order."
|
|
- Check whether the helper-index rebuild triggers correctly on first
|
|
use per sort key (`engine.rs:1604`, `.entry(sort_by...).or_insert_with`)
|
|
— a stale/empty helper index reused across a param rename or
|
|
re-declaration (see the ticket-061-era comments at `engine.rs:225-233`
|
|
about helper indexes needing invalidation when a declaration changes)
|
|
is one plausible cause worth ruling in or out.
|
|
- Check whether the frontend is actually sending `sort_by` on every
|
|
poll/refresh, not just the initial query — a poll path that omits it
|
|
(`webapp/src/lib/polling.ts`) would look exactly like "sorting
|
|
doesn't work" despite correct backend logic.
|
|
- Add visibility for the "still indexing" case the wishlist explicitly
|
|
calls out: if a helper index is being built (or rebuilt) for a
|
|
newly-selected sort key and that's slow enough to be user-visible,
|
|
surface a loading/building state in the timeline UI rather than
|
|
silently returning unsorted or partial results while it builds.
|
|
- Write a regression test once the actual defect is identified —
|
|
ticket 060's existing tests apparently didn't catch this, so identify
|
|
what scenario they miss.
|
|
|
|
## Acceptance criteria
|
|
|
|
- Sorting the timeline by a declared param (including thread
|
|
name/PID-style non-monotonic params) actually reorders displayed log
|
|
entries, verified live in the browser.
|
|
- Sorting by a param that's already effectively time-ordered doesn't
|
|
regress (still displays in the expected order).
|
|
- If a helper index build takes long enough to matter, the UI shows
|
|
that it's building rather than looking broken or stalled.
|
|
|
|
## Depends on
|
|
|
|
Builds on tickets 045, 060, 061 — read those and their resolving
|
|
commits (`de9ba6f` and its predecessor implementing 045) before
|
|
forming a hypothesis.
|