Add Sidekiq worker for group transfer to organization
What does this MR do and why?
Add Sidekiq worker for group transfer to organization
Creates a new Sidekiq worker to handle asynchronous group transfers to organizations. The worker calls Organizations::Groups::TransferService to perform the actual transfer operation.
Key features:
- Idempotent worker that can safely retry on failure
- Low urgency with database health signal deferral
- Sticky data consistency for efficient database load balancing
- Gracefully handles missing records (group, organization, or user)
The worker is located in CE (app/workers) as Organizations is a Community Edition feature.
Related to #431557 (closed)
References
- Issue: #431557 (closed)
- Service implementation:
app/services/organizations/groups/transfer_service.rb
- Sidekiq development guidelines
- Worker attributes documentation
Screenshots or screen recordings
Not applicable - this MR adds a backend Sidekiq worker with no UI changes.
How to set up and validate locally
- Start your GDK and open a Rails console:
gdk start
bundle exec rails console
- Create test data (if needed):
group = Group.create!(name: 'Test Group', path: 'test-group')
organization = Organization.create!(name: 'Test Org', path: 'test-org')
user = User.first # or create a test user
- Enqueue the worker:
Organizations::Groups::TransferWorker.perform_async(group.id, organization.id, user.id)
- Verify the job was enqueued:
Sidekiq::Queue.new('default').size
# Should show at least 1 job
- Process the job (in console or let Sidekiq process it):
Organizations::Groups::TransferWorker.new.perform(group.id, organization.id, user.id)
- Verify the transfer service was called by checking logs or the group's organization:
group.reload.organization_id == organization.id
-
Test idempotency by running the worker multiple times with the same arguments - it should not fail or cause duplicate operations.
-
Test error handling with non-existent IDs:
Organizations::Groups::TransferWorker.new.perform(999999, organization.id, user.id)
# Should return nil without raising errors
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.
-
Code is well-structured and follows GitLab conventions -
Tests added for all code paths -
Worker is idempotent and handles missing records gracefully -
Appropriate worker attributes set (urgency, data consistency, feature category) -
Database health signal deferral configured -
No UI changes required -
Documentation not required (internal worker implementation)