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

2700 improve product refresh scheduling #2701

Merged
merged 3 commits into from
Sep 18, 2018
Merged

2700 improve product refresh scheduling #2701

merged 3 commits into from
Sep 18, 2018

Conversation

mkllnk
Copy link
Member

@mkllnk mkllnk commented Sep 13, 2018

What? Why?

Closes #2700.

When broken delayed jobs are in the database, product cache refreshment fails as described in the issue.

What should we test?

  1. Sign up with an invalid email address that will fail to be delivered: [email protected]
  2. Log in as admin and delete the unconfirmed user account.
  3. Try to create an order cycle with products.

Release notes

Fixed order cycle creation which failed when invalid user accounts were deleted.

Changelog Category: Fixed

@mkllnk mkllnk self-assigned this Sep 13, 2018
j.class == RefreshProductsCacheJob &&
j.distributor_id == distributor.id &&
j.order_cycle_id == order_cycle.id
}.any?
Copy link
Contributor

@sauloperez sauloperez Sep 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the exact difference? although very slow, weren't we checking the same? no ho entenc

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the logic is the same. We check for an identical job.

BUT: The previous implementation needed to call payload_object on each job. That call fails if the object can't be deserialised properly. That happens when the payload object is a user and that user doesn't exist any more. In that case map(&:payload_object) raised Delayed::DeserializationError caused by ActiveRecord::RecordNotFound. Instead of rescueing from that error in a separate each block, I simplified the implementation to just check for the serialised content in the db column handler. That avoids the error and is more efficient.


def self.enqueue_job(job)
Delayed::Job.enqueue job, priority: 10
class << self
Copy link
Contributor

@luisramos0 luisramos0 Sep 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happened here?
I just spent half an hour reading about eigenclasses... my head hurts :-)
In this particular case, is this a convention (use class << self instead of self. ) or is there any change in logic with this?

Copy link
Contributor

@sauloperez sauloperez Sep 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to check what the Ruby Style guide says about it and I'd stick to the community's default. Also, private doesn't work for class methods AFAIK, so I'm not sure here if these methods get hid.

You met the deepest part of Ruby, congrats @luisramos0 :trollface:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm.. I read a bit more about this and actually, this is exactly how you create private class methods :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know! I was a bit reluctant to use class << self here, but I followed rubocop and found that it is the widely accepted way to declare private class methods. I should have tackled one rubocop violation at a time to explain it better. Sorry.

The alternative is to declare it separately:

private_class_method :refresh_job
private_class_method :pending_job?
private_class_method :enqueue_job

That is more repetitive, but you definitely know what it's doing. Should I change it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍
private_class_method is much easier to understand :-)
If it's also correct I'd use it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, please see my additional commit. If you approve, I will squash it with the previous commit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, imo, much better.

@sstead sstead added the pr-staged-au staging.openfoodnetwork.org.au label Sep 18, 2018
@sstead sstead self-assigned this Sep 18, 2018
@sstead
Copy link

sstead commented Sep 18, 2018

Testing notes

I followed the testing steps and was able to create and edit an OC just fine.

https://docs.google.com/document/d/1yU8Zmi10aJcJzb0W8tOGV1GufGgt1uUKEiTY146hElE/edit#

@sstead sstead removed the pr-staged-au staging.openfoodnetwork.org.au label Sep 18, 2018
@sstead sstead removed their assignment Sep 18, 2018
@mkllnk mkllnk merged commit 19df4ff into openfoodfoundation:master Sep 18, 2018
@mkllnk mkllnk deleted the 2700-improve-product-refresh-scheduling branch September 18, 2018 02:09
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

Successfully merging this pull request may close these issues.

4 participants