-
Notifications
You must be signed in to change notification settings - Fork 8
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
#254 Create schedule is adding it disabled and they are ran #255
base: main
Are you sure you want to change the base?
Conversation
if (WorkflowScheduleType.runOnce.equals(scheduleEntity.getType()){ | ||
scheduleEntity.setStatus(WorkflowScheduleStatus.active); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @florentinvintila can you clarify, do we want all schedules to be created active or just runonce schedules?
On line 207 we set the status to trigger_disabled... but the wrapping condition on 206 is that the trigger is enabled. Should we be removing line 207 and just set to active for all types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tlawrie for this case setting all to enabled
seems to be the solution. But I would like to understand what each status represents and for what they were intended to be used.
* fix properties * remove CE labels * fix workflow password parameters * fix conversion * fix conversion * fix conversion * refactor * fix conversion * fix npe * update property processing * upgrade jacoco version
* set default appName for external Nav API * refine UI Header for external navigation URL * default appName to Settings
* This is split from Eventing Branch, with general fixes, not directly related to Eventing * Undo changes for one file * Put back description * Revert some shanges
Hi @florentinvintila @AndreiOla this PR seems to have a whole number of commits pulled in which make it quite hard to review. Do you want to cherry pick the change over to a different branch? or undo some of the commits that have been pulled in that don't relate to the PR? In terms of what is the check meant to be doing, I think it's actually the check that needs to be fixed... Boolean enableJob = false;
if (WorkflowScheduleStatus.active.equals(schedule.getStatus()) && wfEntity.getTriggers().getScheduler().getEnable()) {
scheduleEntity.setStatus(WorkflowScheduleStatus.trigger_disabled);
enableJob = true;
} In the above, I think the check for The reason I say that is
An alternate fix might be needed. |
The solution may be Boolean enableJob = false;
if (WorkflowScheduleStatus.active.equals(scheduleEntity.getStatus()) && wfEntity.getTriggers().getScheduler().getEnable()) {
enableJob = true;
} else if (WorkflowScheduleStatus.active.equals(scheduleEntity.getStatus()) && !wfEntity.getTriggers().getScheduler().getEnable()) {
scheduleEntity.setStatus(WorkflowScheduleStatus.trigger_disabled);
} I can't test it as I am in the middle of v4 of Workflow |
I added the code to this branch. Let me know if it works or not #261 |
hey @florentinvintila checking in on the above... if the solution on the proposed branch is good, we can open a second PR for the v4 branch as well. |
Hi @florentinvintila @amhudson @gchickma checking in if the proposed fix #261 was a fix for this? |
Looks to be |
@tlawrie I think so |
Closes #254
When scheduler is active create schedule is adding it disabled and they are ran.