# 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.