Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gem blows away Sidekiq::Testing.fake! #30

Open
fr2019 opened this issue Jul 15, 2017 · 3 comments
Open

Gem blows away Sidekiq::Testing.fake! #30

fr2019 opened this issue Jul 15, 2017 · 3 comments

Comments

@fr2019
Copy link

fr2019 commented Jul 15, 2017

Using this gem and adding sidekiq_options to a worker with either batch_flush_size or batch_flush_interval as keys blows away Sidekiq::Testing.fake!, causing a lot of my specs to fail. If I remove those keys, the specs run fine.

I'm working around this for now by not applying sidekiq_options in my worker if on Rails.env.test.

Failures:

  1) BuyerInvoice#buy_now_with_payment_method works when specifying a payment method
     Failure/Error: AppboyEventWorker.perform_async(event)

     SocketError:
       getaddrinfo: nodename nor servname provided, or not known
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/connection/ruby.rb:229:in `getaddrinfo'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/connection/ruby.rb:229:in `connect'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/connection/ruby.rb:313:in `connect'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:336:in `establish_connection'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:101:in `block in connect'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:293:in `with_reconnect'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:100:in `connect'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:364:in `ensure_connected'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:221:in `block in process'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:306:in `logging'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:220:in `process'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:187:in `call_pipelined'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:157:in `block in call_pipeline'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:293:in `with_reconnect'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis/client.rb:155:in `call_pipeline'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis.rb:2304:in `block in multi'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis.rb:58:in `block in synchronize'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis.rb:58:in `synchronize'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/redis-3.3.3/lib/redis.rb:2296:in `multi'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-grouping-1.0.9/lib/sidekiq/grouping/redis.rb:16:in `block in push_msg'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq.rb:95:in `block in redis'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/connection_pool-2.2.1/lib/connection_pool.rb:64:in `block (2 levels) in with'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/connection_pool-2.2.1/lib/connection_pool.rb:63:in `handle_interrupt'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/connection_pool-2.2.1/lib/connection_pool.rb:63:in `block in with'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/connection_pool-2.2.1/lib/connection_pool.rb:60:in `handle_interrupt'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/connection_pool-2.2.1/lib/connection_pool.rb:60:in `with'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq.rb:92:in `redis'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-grouping-1.0.9/lib/sidekiq/grouping/redis.rb:78:in `redis'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-grouping-1.0.9/lib/sidekiq/grouping/redis.rb:15:in `push_msg'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-grouping-1.0.9/lib/sidekiq/grouping/batch.rb:15:in `add'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-grouping-1.0.9/lib/sidekiq/grouping/middleware.rb:37:in `add_to_batch'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-grouping-1.0.9/lib/sidekiq/grouping/middleware.rb:25:in `call'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq/middleware/chain.rb:133:in `invoke'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq/client.rb:206:in `process_single'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq/client.rb:65:in `push'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq/worker.rb:116:in `client_push'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/sidekiq-4.2.10/lib/sidekiq/worker.rb:60:in `perform_async'
     # ./app/classes/appboy_event.rb:11:in `put'
     # ./app/models/invoices/buyer_invoice.rb:338:in `block in pay_with_payment_method!'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/test_after_commit-1.1.0/lib/test_after_commit/database_statements.rb:11:in `block in transaction'
     # /Users/cisco/.rvm/gems/ruby-2.3.4/gems/test_after_commit-1.1.0/lib/test_after_commit/database_statements.rb:5:in `transaction'
     # ./app/models/invoices/buyer_invoice.rb:252:in `pay_with_payment_method!'
@ibrahima
Copy link

Is this also the reason that enqueuing Sidekiq-grouping enabled jobs in a test results in the job being pushed to the user's development Redis and getting processed (and usually failing) in the dev Sidekiq environment?

@le0pard
Copy link
Contributor

le0pard commented Nov 27, 2018

Version 1.0.10 contain method force_flush_for_test! for Sidekiq::Testing.fake!

@ibrahima
Copy link

Ahh, using force_flush_for_test! fixes the issue I was seeing. I guess it's because Sidekiq::Grouping has its own queues separate from Sidekiq, and they aren't namespaced, so if your test environment shares the same Redis instance as your dev environment, the Sidekiq::Grouping queues will eventually get flushed into your main Sidekiq dev queues. It's probably best to fix this by using separate Redis instances, but it's kinda annoying to set up your local testing environment like that 🤷.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants