Sidekiq doesn't have any features to limit memory usage or execution
time. We need a separate process for this. Forking avoids the boot time
of a fresh process and copy-on-write ensures minimal memory overheads.
This is supposed to lower the memory footprint of all Puma workers. The
reports code will occupy needed memory in one Sidekiq worker instead of
in several Puma processes.
The current code doesn't limit the execution time yet. We either need a
way to terminate the report rendering after a while or send an email
with a link to access a rendered report.
The ReportsController was referencing the report and the report was
referencing the controller. It's unlikely that this circular dependency
created a memory leak but it's generally a bad design. And we need to
make the reporting independent of the controller to isolate it in a
background job.
Controller is constrained by FeatureToggle
- new_products_page
- and available on '/new_products'
Add simple view for new products page and a product
Add new products page as a new entry in the menu
In March 2020 this was changed to use :size instead of :count because TagRuleApplicator returned an ActiveRecord::Relation, see:
d2eee1dafd
However in October 2020 TagRuleApplicator was changed to always return an Array so this is no longer needed, see:
7e606471e4
It was checking for the permission to create a user which everyone can
do. Now it's checking for updating that particular user and doesn't
allow generating new keys for other users any more.
This would have been an inconvenience but not a big security issue
because you can't view the key of another user.
Before the Shop::OrderCyclesList service would return order cycles even if they are not ready for checkout and we had a check before calling the service in BaseController which would return OrderCycle.where('false'). It seems like this check should be part of the service too.
Instead we will make sure the order cycle is not available on the shopfront if it is doesn't have valid shipping methods. This will preven the issue where if one distributor deletes their shipping method, we don't want to invalidate the order cycle for all other distributors.
Co-authored-by: Maikel <maikel@email.org.au>
If a distributor order cycle has no shipping methods it will be invalid. This is a bit confusing because adding a check for :invalid seems like it would be better if it was done in the Shop::OrderCyclesList service but the hack doesn't work if you put it in there, it seems like something needs a refactor.
