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

v6.0.1 completely broke sidekiq-unique-jobs #4308

Closed
mhenrixon opened this issue Oct 3, 2019 · 14 comments
Closed

v6.0.1 completely broke sidekiq-unique-jobs #4308

mhenrixon opened this issue Oct 3, 2019 · 14 comments

Comments

@mhenrixon
Copy link
Contributor

mhenrixon commented Oct 3, 2019

Ruby version:
Sidekiq 6.0.1:

https://travis-ci.com/mhenrixon/sidekiq-unique-jobs/jobs/241465466 broke when you released 6.0.1.

I also had the following issue reported: mhenrixon/sidekiq-unique-jobs#427 which matches perfectly with the broken test suite.

Any ideas what the broken change might be? Seems like you should have made that bump to version 7 not 6.0.1 :)

@mhenrixon
Copy link
Contributor Author

I'm really not trying to be sarcastic (just funny). Did you make sidekiq too fast perhaps? 🤣💣

@mperham
Copy link
Collaborator

mperham commented Oct 3, 2019

The only change that I can think that might have changed some middleware semantics accidentally is #4303.

@mhenrixon
Copy link
Contributor Author

Hmm, that does indeed look like a potential problem! Let me check if reverting that fixes the issue

@mhenrixon
Copy link
Contributor Author

Yup @mperham when I revert the commit in https://github.com/mhenrixon/sidekiq test pass just fine.

@mperham
Copy link
Collaborator

mperham commented Oct 3, 2019

I would like to understand the problem with the change. Can you send me a script or unit test which reproduces the behavior?

@mhenrixon
Copy link
Contributor Author

sidekiq-unique-jobs 2019-10-03 22-24-32

It seems (in test suite also) that since 6.0.1 no jobs get actually pushed to redis anymore. This is of course because of the middelware handling or something.

By closer examination it doesn't seem like the marshaling/performance PR.

@mhenrixon
Copy link
Contributor Author

class BuildDistributorWorker
  include Sidekiq::Worker

  sidekiq_options lock: :until_executing, log_duplicate_payload: true, queue: :build_distributors

  def perform(id); end
end

That type of lock should always allow to be pushed, it only locks during processing (when the server processor is picking it off the queue). My guess is that some part of the code that either deals with the push or the middleware changed in 6.0.1.

@mhenrixon
Copy link
Contributor Author

Pretty sure this broken the build: daabec1

@fatkodima
Copy link
Member

It seems like changes in logger context handling (one pr after this) broke this.
This code from your gem

  def with_context(context, &block)
    if logger.respond_to?(:with_context)
      logger.with_context(context, &block)
    elsif defined?(Sidekiq::Logging)
      Sidekiq::Logging.with_context(context, &block)
    end
  end

not recognizes new changes (Sidekiq::Context.with), so not working as expected.

@mhenrixon
Copy link
Contributor Author

Too late @fatkodima I already pointed that out :)

@fatkodima
Copy link
Member

fatkodima commented Oct 3, 2019

That's because I was typing this here slowly 😄

@mhenrixon
Copy link
Contributor Author

That code is naive anyway but gosh it is getting annoying to maintain all the various logging contexts from sidekiq 🤣

Can you just decide on a way to do this and stick to it? 🥳🤨

@mhenrixon
Copy link
Contributor Author

Ok, I'll add some tests for it. My problem is that I want to piggy-back on the sidekiq logger to provide some sensitive extra values to the logger. Maybe I should just scrap that and build my own instead. Been thinking about it for some time but it always seemed so unnecessary.

@mhenrixon
Copy link
Contributor Author

Closing this, thanks for the quick feedback everyone!

PS. I love this last refactoring you did on Sidekiq::Context @mperham. The Sidekiq::Logging or whatever used to be pretty hairy if you ask me!

Ever thought of using something like twp/logging which kind of does a lot of that stuff already?

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