about summary refs log tree commit diff
path: root/app/workers/thread_resolve_worker.rb
diff options
context:
space:
mode:
authorThibG <thib@sitedethib.com>2017-11-11 16:49:04 +0100
committerEugen Rochko <eugen@zeonfederated.com>2017-11-11 16:49:04 +0100
commit2b1190065c54f071ae384f6e05b4a087987febba (patch)
treeec9ea4cf47eee895e59d8b8feb90e325f4ee259f /app/workers/thread_resolve_worker.rb
parent56720ba590bf988a5feba22fc6c8ace473ff30a4 (diff)
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.
Diffstat (limited to 'app/workers/thread_resolve_worker.rb')
-rw-r--r--app/workers/thread_resolve_worker.rb6
1 files changed, 5 insertions, 1 deletions
diff --git a/app/workers/thread_resolve_worker.rb b/app/workers/thread_resolve_worker.rb
index 38287e8e6..c18a778d5 100644
--- a/app/workers/thread_resolve_worker.rb
+++ b/app/workers/thread_resolve_worker.rb
@@ -3,7 +3,11 @@
 class ThreadResolveWorker
   include Sidekiq::Worker
 
-  sidekiq_options queue: 'pull', retry: false
+  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)