resque / resque/resque-scheduler
(set|remove)_schedule should respect Resque.inline
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 1.7k
- Forks
- 477
- PR merge metrics
- No merged PRs in 30d
Description
much like #503 on delayed jobs, setting/removing schedules should also respect Resque.inline
I am moving Resque.schedule = lines from rake task to rails initializer,
to make schedules available in schedule tabs https://github.com/resque/resque-scheduler/issues/541#issuecomment-224886592 .
But doing so breaks my ci test environments, where I set Redis.inline = true and still gets complains Redis::CannotConnectError (exactly what @benthorner is seeing at https://github.com/resque/resque-scheduler/issues/541#issuecomment-218894599 )
README should be updated, schedlue tab was maybe the reason for https://github.com/resque/resque-scheduler/issues/563#issuecomment-229021293 ,
and I might be (very likely) misunderstanding about difference between (persisted|non-persisted schedule
(I am not using dynamic scheduler, and really confused which one I should be using
when all I want to do is load schedule from yaml, update schedule on deploy by restarting scheduler, use schedule-tab for manual kicking)
but ANYWAYS (set|remove)_schedule should work without connection to redis when Resque.inline is set to true.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the set_schedule and remove_schedule entry points and compare their intended inline behavior with the delayed-job change in issue #503. Verify the behavior when Resque.inline is true and Redis is unavailable, then check the README context around persisted and non-persisted schedules. Done means both operations work without a Redis connection in inline mode and the documented behavior is clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- redis, ruby
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100