A list's trace says which list it was (#287)
The prod check of 2026-10-19 found /api/entries requests of 0.5-0.8 s overnight beside others of 80-100 ms on an idle host, the time all in entries_in, and nothing in the trace said which filter, sort or page they were. The step now carries them, and whether a search, not its words. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -185,7 +185,7 @@ a count says something happened, the lines and traces say why.
|
||||
`feed` or `fetch` span holding most of it (`$Q spans '{... && name="feed" && duration > 10s}'`),
|
||||
or a `download` far slower than its size explains.
|
||||
|
||||
Steps are `step` spans named by `of` (#187): an item list's `entries_in`, `sanitize`,
|
||||
Steps are `step` spans named by `of` (#187): an item list's `entries_in` (with the list asked for: `filter`, `sort`, `dir`, `offset`, `limit`, `search`), `sanitize`,
|
||||
`deadair`, `count_in`; the feed list's `catalogue`, `feed_list` and its queries; a `reap`'s
|
||||
`missing_files`, `prune_abandoned_failures`, `reap_candidates`, `clean_directory` (once a day
|
||||
since #193, so a reap is about a second), `trim_artwork`, with what it removed on the `reap`
|
||||
|
||||
Reference in New Issue
Block a user