Closed joshrieken closed 9 years ago
This still seems to be a problem. Shall we fix this or update the documentation?
Pull requests are welcome!
On Tuesday, May 26, 2015, Christian Felder notifications@github.com wrote:
This still seems to be a problem. Shall we fix this or update the documentation?
— Reply to this email directly or view it on GitHub https://github.com/facto/fist_of_fury/issues/2#issuecomment-105471549.
I have been digging into this issue, but I got stuck. It looks like the IceCube recurrence rules get properly set on the FistOfFury::Schedule instance the object holds, no matter if they are set in the class at load time, via direct call at runtime with WhateverJob.recurs
or the FistOfFury.attack!
block.
WhateverJob.schedule.ice_cube_schedule.recurrence_rules
returns the correct objects in all cases. But I can confirm, that the jobs are not scheduled when recurrence is set in the class at load time.
So far it looks like the schedules are properly being set up. Any idea where to look next?
@masone Finally got around to this! Thanks for making the effort to look into it.
The problem isn't with fist_of_fury, per se. It has more to do with Rails and its default eager loading behavior. If you check your development.rb
, you'll probably find:
config.eager_load = false
This results in the job classes not being loaded, meaning the recurs
block is never run, and ultimately meaning the job is never scheduled.
To fix this, either change eager_load
to true
or simply reference your job class somewhere (perhaps in config/initializers/fist_of_fury.rb
).
For now, rules must be defined in a block passed to FistOfFury.attack!.