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

always include foodcoop as parameter to a workerjob #1083

Merged
merged 1 commit into from
Feb 6, 2025

Conversation

mortbauer
Copy link
Contributor

  • the way it was before failed jobs wouldn't run correctly anymore after the had failed because of the wrong scope
  • now it is a bit more explicit but jobs can be re-run

Copy link
Member

@wvengen wvengen left a comment

Choose a reason for hiding this comment

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

Ah, this seems to make sense.
Was this broken? If so, we may want to have this tested (but not for this PR).

As selecting the foodcoop scope is something used in various jobs, I would expect something like a before_action in the controller, but then for a job, or something similar. This action would be defined in the ApplicationJob.

I think the monkey-patching in the initializer is not the most beautiful approach, but it shows that we may want to have a generic way to select the foodcoop scope in a job. But perhaps this is hard to get right from an ApplicationJob or so.

I think if we'd resort to passing the foodcoop scope to perform_later, then we don't need the monkey-patch at all, right? Then perhaps a keyword scope argument may make sense, with the default nil for perform and the current scope for perform_later. Just some thoughts on making this a bit clearer.

@mortbauer
Copy link
Contributor Author

I agree, actually I already found issues because activestorage jobs would then not run with the correct foodsoft selected, I think I found a better generic solution now.

@mortbauer mortbauer force-pushed the fix/worker-jobs branch 2 times, most recently from 838f796 to 29325ca Compare February 4, 2025 09:30
@mortbauer
Copy link
Contributor Author

I updated the pull request with a generic working solution.

Copy link
Member

@wvengen wvengen left a comment

Choose a reason for hiding this comment

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

Ah, this is clearer. And as it this functionality is currently broken, I'd be willing to accept it as it is.

But I think there could be a cleaner solution that does not involve monkey-patching: can we make this a job concern, and include/extend it in each job that needs to select the foodcoop? It sounds to me like job callbacks could be used here instead, as a more standard mechanism. And perhaps a custom serializer to store the current scope. Let me know what you think.

@mortbauer
Copy link
Contributor Author

yes a custom serializer could maybe work, but maybe also not because we already had serialize and deserialize overwritten which worked when normally scheduling the job, but somehow when retrying via resqueue it seemed to nether call serialize again but deserialize it would call again, resulting in an Exception obviously.
Making it a job concern is what I had in the 1 st version, but there are rails activestorage jobs which are also running and I think they might also need to run in the proper scope.

@wvengen
Copy link
Member

wvengen commented Feb 4, 2025

Ah, that makes sense! Then this change seems good to me 👍

I see that the tests are failing, could you confirm that they pass locally, and rubocop too?

@mortbauer
Copy link
Contributor Author

Can confirm that the test run, actually I created a pull request #37 where i slightly changed the dockerfile to use multistage building and use a target to run the tests, which I added as new workflow there.

@wvengen
Copy link
Member

wvengen commented Feb 6, 2025

Thank you! 👍

@wvengen wvengen merged commit e91fc18 into foodcoops:master Feb 6, 2025
1 of 3 checks passed
# Override the `_perform_job` method
define_method(:_perform_job) do
foodsoft_scope = @arguments.shift
FoodsoftConfig.select_foodcoop foodsoft_scope
Copy link
Member

Choose a reason for hiding this comment

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

i think this works only for multi-coop mode and could be the reason why the tests fail with the default app_config.yml

Copy link
Member

Choose a reason for hiding this comment

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

Ouch, I'm sorry not to have checked that!

Copy link
Member

Choose a reason for hiding this comment

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

that's okay! Any idea how we can mitigate this?
just a wild guess:

      if FoodsoftConfig[:multi_coop_install]  do
        foodsoft_scope = @arguments.shift
        FoodsoftConfig.select_foodcoop foodsoft_scope
      end

Copy link
Member

@wvengen wvengen Feb 6, 2025

Choose a reason for hiding this comment

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

Or even only doing the monkey-patch for multi-coop installs, perhaps?
(with the downside that it's not tested, but perhaps it would be good to run CI tests with and without multicoop? that would be a different issue though)

Copy link
Member

Choose a reason for hiding this comment

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

But perhaps it's not a good idea to read the config early on (it may involve database access, but didn't check).
The easiest solution may be

foodsoft_scope = @arguments.shift
FoodsoftConfig.select_foodcoop foodsoft_scope if FoodsoftConfig[:multi_coop_install]

We'd better shift also for singlecoop.

Copy link
Member

Choose a reason for hiding this comment

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

alright, wasn't sure about what @arguments contains and if it needs to be shifted if called in a single-coop setting. I'll give this a try! :)
Having a pipeline testing multi-coop would be great, yes!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes it only works for multicoop, but not only with my change, was only working with mulricoop since years

yksflip added a commit to yksflip/foodsoft that referenced this pull request Feb 6, 2025
yksflip added a commit that referenced this pull request Feb 6, 2025
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.

3 participants