"transaction" metrics from workers are not collected
In !48024 (merged) we removed Gitlab::Metrics::SidekiqMiddleware and Gitlab::Metrics::BackgroundTransaction, and stopped providing a Transaction during Sidekiq job execution, which means calls to Gitlab::Metrics.add_event from workers stopped collecting metrics. This was partially reverted (rejigged, really) in !56005 (merged) to restore necessary metrics, but this didn't have any effect on Gitlab::Metrics.add_event because the new BackgroundTransaction has a different thread key (BACKGROUND_THREAD_KEY), and https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/metrics.rb#L32 explicitly uses Transaction.current which uses the default/base THREAD_KEY.
All of that is fine; we haven't had these metrics since Nov 2020, but there is code in some workers still trying and failing (cleanly, because of the & in [add_event)(https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/metrics.rb#L27)) to record the metrics:
app/workers/repository_import_worker.rb: Gitlab::Metrics.add_event(:import_repository)
app/workers/stuck_export_jobs_worker.rb: Gitlab::Metrics.add_event(:stuck_export_jobs,
app/workers/gitlab/import/stuck_project_import_jobs_worker.rb: Gitlab::Metrics.add_event(
app/workers/gitlab/jira_import/stuck_jira_import_jobs_worker.rb: Gitlab::Metrics.add_event(:stuck_jira_import_jobs,
app/workers/repository_fork_worker.rb: Gitlab::Metrics.add_event(:fork_repository)
This is not breaking anything, but is unclean. IMO there are two options:
- Declare we don't want them, and remove those add_event calls
- Fix it so they work
I don't know the method to achieve option 2, but the decision on whether we try needs to be made first, and if we choose not to, we should take option 1.
/cc @smcgivern @qmnguyen0711 as relevant parties involved in the original changes.