search

brandonhilkert / sucker_punch

Sucker Punch is a Ruby asynchronous processing library using concurrent-ruby, heavily influenced by Sidekiq and girl_friday.
MIT License
2.64k stars 114 forks source link

Inline testing is asynchronous when accessed through a Rack interface #65

Closed whittle closed 10 years ago

whittle commented 10 years ago

SuckerPunch has been working great for me—thank you for making Celluloid so easy to integrate into a web app.

I have run into one strange problem: while requiring "sucker_punch/testing/inline" in my spec helper works as advertised under normal conditions, I have found a circumstance under which it does not.

I am testing a Rails app (which uses SuckerPunch) that exclusively serves JSON, and I wanted to have an integration suite that tests the app and its dedicated client gem against one another. The client gem uses Faraday, so after requiring "sucker_punch/testing/inline" I configure the client gem’s Faraday instance to use the Rack adapter with my Rails.application. This set-up works great for end-to-end testing, except for the fact that if the client performs an action which triggers a SuckerPunch job, that job is run asynchronously despite the fact that "sucker_punch/testing/inline" was previously required.

The situation is all the more confusing because in the same app and spec suite, other specs which are not going through the Faraday/Rack adapter correctly inline asynchronous jobs. The shared connection hack mentioned in #15 fixes the issue, but creates more problems than it solves (causes sporadic hangs and segfaults). My present work-around is to add sleep statements to my specs before checking the database for job results, but this is undesirable.

I have found this problem to occur using SuckerPunch 1.1 and 1.0.5 and Rails 4.1.1 and 4.1.4.

brandonhilkert commented 10 years ago

Man, I don't know off-hand. Is that something the Faraday support could help with?

I don't know what's going on under the hood when Faraday is setup. It seems directly related to Faraday given that the other jobs are running synchronously.

whittle commented 10 years ago

For the curious, I now believe that this was caused by an issue with the spring gem. Upgrading to spring-1.1.3 seems to have fixed the problem.

brandonhilkert commented 10 years ago

Nice. Thanks for following up! I'm sure someone will hit something similar as more Apps move to Rails 4.1+.