ottyl/tickets/074-timeline-sort-still-broken.md

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.