Thread resolving is one of the few tasks that isn't retried on failure. One common cause for failure of this task is a well-connected user replying to a toot from a little-connected user on a small instance: the small instance will get many requests at once, and will often fail to answer requests within the 10 seconds timeout used by Mastodon. This changes makes the ThreadResolveWorker retry a few times, with a rapidly-increasing time before retries and large random contribution in order to spread the load over time.
		
			
				
	
	
		
			21 lines
		
	
	
	
		
			479 B
		
	
	
	
		
			Ruby
		
	
	
	
	
	
			
		
		
	
	
			21 lines
		
	
	
	
		
			479 B
		
	
	
	
		
			Ruby
		
	
	
	
	
	
| # frozen_string_literal: true
 | |
| 
 | |
| class ThreadResolveWorker
 | |
|   include Sidekiq::Worker
 | |
| 
 | |
|   sidekiq_options queue: 'pull', retry: 3
 | |
| 
 | |
|   sidekiq_retry_in do |count|
 | |
|     15 + 10 * (count**4) + rand(10 * (count**4))
 | |
|   end
 | |
| 
 | |
|   def perform(child_status_id, parent_url)
 | |
|     child_status  = Status.find(child_status_id)
 | |
|     parent_status = FetchRemoteStatusService.new.call(parent_url)
 | |
| 
 | |
|     return if parent_status.nil?
 | |
| 
 | |
|     child_status.thread = parent_status
 | |
|     child_status.save!
 | |
|   end
 | |
| end
 |