FIX: Slow test (deadlock)

FIX: Slow test (deadlock)

It was getting caught in a DistributedMutex deadlock (twice!), which meant this test was taking 120s to run.

I’m not sure why queue jobs was turned off here, because when I turn it on the test passes and takes <2s instead.

diff --git a/spec/components/cooked_post_processor_spec.rb b/spec/components/cooked_post_processor_spec.rb
index 938c9c8..4f5e280 100644
--- a/spec/components/cooked_post_processor_spec.rb
+++ b/spec/components/cooked_post_processor_spec.rb
@@ -1228,12 +1228,10 @@ describe CookedPostProcessor do
     end
 
     it "works only on new posts" do
-      SiteSetting.queue_jobs = false
-
-      hidden = Fabricate(:post, topic: topic, hidden: true, raw: "this is the second post after")
-      small_action = Fabricate(:post, topic: topic, post_type: Post.types[:small_action])
-
+      Fabricate(:post, topic: topic, hidden: true, raw: "this is the second post after")
+      Fabricate(:post, topic: topic, post_type: Post.types[:small_action])
       reply = PostCreator.create!(topic.user, topic_id: topic.id, raw: raw)
+
       CookedPostProcessor.new(reply).post_process
       expect(reply.raw).to eq(raw)

GitHub sha: 34b2157b

2 Likes

Do you happen to remember which DistributedMutex lock it was getting stucked on? Our tests do not run anything in parallel so The lock should be a noop.

It’s not due to concurrency. A distributed mutex is created during the cooked post processor and if a certain condition is true, it triggers a post revision which re-enters the same method and wants another DistributedMutex.

If you want to reproduce it’s quite easy, simply revert my commit.

1 Like

Ahh icic. I’ll have a look since this sounds like a bug that can cause a deadlock even in production.

I looked at that @tgxworld and it didn’t seem possible since cooked processor enqueues jobs in production, but it would be great to have a second pair of :eyes: to confirm it.

@eviltrout Yup I can confirm that too.

1 Like