Traces cannot say where a slow reap, episode list or DeadAir pass spends its time #187
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found in the prod check of 2026-10-11. Reaps took 12-47 s between 01:40 and 01:43 UTC (trace 932124949f63d3b76184704bb98f278) against 1-6 s usually, and the trace is one span with nothing inside, so which part was slow (checking every file on disk, the database, deleting) could not be told. GET /api/entries is the slowest regular request (837 ms p95) with no steps either, and DeadAir's analysis of a file has no trace at all, only a log line with its total time. Add steps to each.
Done in
e5b9b0c, deployed. Verified in Tempo: a reap now shows missing_files 10 ms, prune_abandoned_failures 7 ms, reap_candidates 141 ms, clean_directory 2254 ms, trim_artwork 110 ms, with files/bytes/entries on the reap span (trace 7f6fb753348332d0c068c5ed29ba47d1); an episode list shows entries_in 939 ms of 1002 (c3700464f90542301193c5e6f41975d7). DeadAir's per-file trace appears with the next episode it analyses.