mastodon/app/workers/thread_resolve_worker.rb

# 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
Restoring old async behaviour of thread resolving as it proved to be more robust 2016-12-12 21:12:19 +01:00			`# frozen_string_literal: true`

			`class ThreadResolveWorker`
			`include Sidekiq::Worker`

Retry thread resolving (#5599) 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. 2017-11-11 16:49:04 +01:00			`sidekiq_options queue: 'pull', retry: 3`

			`sidekiq_retry_in do \|count\|`
			`15 + 10 * (count*4) + rand(10 (count**4))`
			`end`
Improve background jobs params and error handling 2017-01-05 03:28:21 +01:00
Restoring old async behaviour of thread resolving as it proved to be more robust 2016-12-12 21:12:19 +01:00			`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`