The feed list's traces do not say where its 290 ms goes #164
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 2026-10-09 while following up #159. GET /api/feeds takes 250-300 ms in production (traces ebfe8ec1076101fb673271fb0f74f4b8, 25bc590258866a51b4690a40c3e8fb9d), and its trace has nothing under it but feed_summary spans of about 1 ms: the catalogue (subscriptions()), the person's subscriptions, the subscriber counts, the pins and feed_list's five queries are untraced, so there is no telling which costs what.
Wanted: a span for each, only inside a request or a scan. The healthcheck's status (every 30 s) and the page's live updates run the same code outside any trace, and a span there is a trace of its own: feed_summary already shows up as one-span root traces that way.
Done in
6a69818: feed_rows wraps each of its steps in a step span, and feed_list each query; db::step makes one only inside a request or scan, and the last 10 minutes show step spans in GET /api/feeds traces and nowhere else. Deployed as 0.10.3-dev. What they show is #165.