whippy-edition/app/workers/thread_resolve_worker.rb

# frozen_string_literal: true

class ThreadResolveWorker
  include Sidekiq::Worker
  include ExponentialBackoff

  sidekiq_options queue: 'pull', retry: 3

  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-13 05:12:19 +09:00			`# frozen_string_literal: true`

			`class ThreadResolveWorker`
			`include Sidekiq::Worker`
Improved remote thread fetching (#10106) * Fetch up to 5 replies when discovering a new remote status This is used for resolving threads downwards. The originating server must add a “replies” attributes with such replies for it to be useful. * Add some tests for ActivityPub::FetchRepliesWorker * Add specs for ActivityPub::FetchRepliesService * Serialize up to 5 public self-replies for ActivityPub notes * Add specs for ActivityPub::NoteSerializer * Move exponential backoff logic to a worker concern * Fetch first page of paginated collections when fetching thread replies * Add specs for paginated collections in replies * Move Note replies serialization to a first CollectionPage The collection isn't actually paginable yet as it has no id nor a `next` field. This may come in another PR. * Use pluck(:uri) instead of map(&:uri) to improve performances * Fix fetching replies when they are in a CollectionPage 2019-02-28 23:22:21 +09:00			`include ExponentialBackoff`
Restoring old async behaviour of thread resolving as it proved to be more robust 2016-12-13 05:12:19 +09:00
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-12 00:49:04 +09:00			`sidekiq_options queue: 'pull', retry: 3`

Restoring old async behaviour of thread resolving as it proved to be more robust 2016-12-13 05:12:19 +09: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`