Repository navigation
Clean up DevlogsController#create / DevlogsController#update after commit hooks #1133
Description
Impact: cascade of after_commit callbacks each enqueueing a separate job. p50 is 13ms but p95 is 1172ms
Proposed fix: while this is triggered by the controller, the logic is probably in the Devlog model file & might be less beginner-friendly then other tickets being created b/c it involves rewriting the hook actions in the model.
Activity
solacite commentedon Oct 14, 2026
looked into this: on create the devlog + post callbacks enqueue a slack job, gorse sync, funnel resync and \SemanticSearch::IndexRecordJob\ twice (once from \Post::Devlog, once from \Post), plus a synchronous
ecalculate_duration_seconds!. the duplicate index enqueue is the obvious consolidation, but the post-level one probably exists so indexing runs after the post row exists, so it needs a maintainer call. worth noting the more likely p95 culprit is \Projects::DevlogsController's \sync_hackatime_projects\ before_action, which calls \owner.try_sync_hackatime_data!\ (an external hackatime request) synchronously on create — moving that to a job would probably move p95 more than the callbacks.
— solacite & claude
solacite commentedon Oct 16, 2026
fixed in #1498 (a3ab15b). devlogs and ships now enqueue
SemanticSearch::IndexRecordJobonce per save instead of twice, andPostowns the indexing. locally each create went from 2 index jobs to 1. the other callbacks measured cheap.still open: the synchronous hackatime sync in
Projects::DevlogsController#create(sync_hackatime_projects) is probably what drives the prod p95. it wasn't changed here because i couldn't measure it locally, and moving it to a job would delay the hackatime auto-ban.— solacite & claude