Skip to content

Find Gaps in Improved User Mapping Logging

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

This issue is to identify whether logging we have implemented during development of improved user mapping features is sufficient, and if there's any place we think we should add logging. Once we begin to roll out improved user mapping, it's possible that new issues will arise. Having logging throughout the user mapping process should help make it easier to identify what was happening in case a customer encounters a new issue, and helping the rollout go smoother. We currently have the following pieces of user mapping logged:

Direct Transfer Export contributions relation

  • error is logged if the contributions export job is stuck without data to export.
  • User Contributions are exported using RelationExportService, so errors are logged like any other exported relation.

Direct Transfer update placeholder data from contributions relation

There's an open MR for this: Add worker to populate import source user missi... (!164420 - merged) so this is subject to change

  • error logged when there's an error updating the import source user or its placeholder user fails to update

All Importers create Import::SourceUsers

  • Gitlab::Import::SourceUserMapper calls Import::PlaceholderUserLimit to check if the placeholder user limit has been exceeded. If it has, info is logged before continuing
  • warn logged when creating an Import user fails due to ActiveRecord::RecordNotUnique error before finding the existing record again (i.e. race condition occurred and need to find existing import user)
  • When Gitlab::Import::ImportFailureService is called, an error is logged and the exception is tracked. It's our basic error tracking and logging service used is in our main importers: GitHub, Bitbucket, Bitbucket Server, and import/export.

Reassignment process

  • warn is logged if the Import::SourceUser does not exist or is not in reassignment_in_progress status. This check also prevents Import::ReassignPlaceholderUserRecordsService from executing.
  • error is logged if the model cannot be aliased to a real model for reassignment
  • warn is logged if the contribution record is invalid or not unique and cannot be reassigned. This single record is skipped, but reassignment of valid records continues.
  • error is logged if the reassignment worker, Import::ReassignPlaceholderUserRecordsWorker, retries 5 times and fails each time

Potentially risky reassignments are also logged with warn in an open MR: Log when there is a potentially risky reassignment (!165029 - merged) for the following scenarios:

  • when the destination user is an admin. See additional details in confidential issue: #474963 (closed)
  • when the destination user has a different domain from the user who triggered the reassign

If there's any other notable scenarios that need to be logged, those should be added. If what we have currently, merged or in development, is enough, this issue can be closed.

Edited by 🤖 GitLab Bot 🤖