Extend SyncPipelineExecutionPolicyMetadataWorker log context

What does this MR do and why?

Extend SyncPipelineExecutionPolicyMetadataWorker so its log lines carry enough context to be searchable per project and per customer.

Previously, when AnalyzePipelineExecutionPolicyConfigService failed inside the worker, the emitted warning only included the worker class name and the error message — no project, no user, no policy identifiers. That made it effectively impossible to find errors for a specific project or customer in Kibana.

Changes:

  • Wrap the worker body in with_context(project: config_project, user: user). This pushes the values onto Gitlab::ApplicationContext, so every log line emitted inside the block (including from downstream services) gets meta.project, meta.user, meta.user_id, and meta.root_namespace injected by Labkit's logger formatter — matching the structure the rest of the worker fleet uses.
  • Include security_policy_ids in the failure payload so the affected policies are also searchable.

References

How to set up and validate locally

  1. In a rails console, enqueue the worker with arguments that will fail analysis (e.g. a user that does not have access to the config project):
    Security::SyncPipelineExecutionPolicyMetadataWorker.new.perform(config_project.id, user.id, 'invalid', [policy.id])
  2. Inspect the resulting log line in log/sidekiq.log and confirm it now includes meta.project, meta.user, meta.user_id, correlation_id, and security_policy_ids.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Martin Cavoj

Merge request reports

Loading
Loading