This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
For the second time since implementing 2018.3, I've had workflow schedules suddenly update to a Disabled status on the Gallery, without being changed in any way. While it is pretty straightforward to re-enable these, it has caused us to miss a few scheduled runs.
Does anyone have any thoughts on what can cause a schedule to switch to a "Disabled" state?
The causes can range a bit, but usually when you click Edit on the Schedule that's Disabled, there should be a message in red that will provide a reason for why it's disabled.
However, sometimes these may not be too useful. As an example, you may also see something in the Service Logs or Event Logs with something like this -
Corrupt: PersistenceContainer_MongoDBImpl_Get_Error: Record identifier is invalid <5bexxxxxxxxxxxxxxxxx1f9> collection <AS_Queue>
The Schedule tries to obtain/perform next runs based on the Queue (but also refers to other tables within the Mongodb). In this example, the record in the Queue that corresponded to this job was made corrupt, so the Schedule would never be able to calculate the Next Run and so the Schedule was disabled. There are similar instances to something like this, where an entry in one of the Mongo tables gets corrupt and the Schedule can't perform it's normal tasks.
These corruptions can come from a variety of things, most notably from abrupt stops or unclean shutdowns to the Alteryx Service, reasons ranging from a crash to the Service or the Server rebooting.
You should be able to see the error in the Gallery Logs (but you may also wish to check the Service Logs as well).
If this unexpected disabled issue is consistently occurring, I would advise to contact email@example.com and explain the situation best you can.
I did find out yesterday (by pure coincidence) that some administrative activities, such as a user moving between private studios, also seem to disable schedules, even if those schedules are not yet set to run.
I'm not sure of the exact reason for this, but wanted to include that finding.
I could relate to moving between the private studios. Because I did just that before it was disabled. And I see that happens almost everytime I do that. I think it could be a bug in Alteryx or is it expected behavior?
1) yes, when individuals move from one private studio to another private studio, the workflow from the initial private studio will become "disabled"; there are other posts on this topic. I haven't seen a perfect "work-around". As an Admin, I jump from private studios to see others' workflows. So yes, it's a problem if I run scheduled workflows from my own private studio. (Though, I think, if you get back into the initial private studio before the scheduled run, it will not become disabled....but I'm not 100% positive on that).
2) another thing I noticed with 2018.2, if your viewing scheduled workflows and you "cancel" a workflow in the "queue", that workflow will become "unscheduled"...showing up as "completed" in the Admin Gallery. If you cancel a workflow that is "running", you don't get that behavior; it will run on it's next scheduled run.
So I've been doing some more digging and have confirmed certain behaviors that will disable schedules. The following are intended -
1) If the app is deleted
2) A revision was deleted
3) The schedule owner was deleted
4) The owner of the app was deleted
5) The users permission to that app was removed
6) If the user doesn’t have the credentials assigned to that app anymore
7) As we've discovered, moving private studios (this can also fall under reason (6) as the permissions change when moving private studios)
8) If credentials are expired, Scheduler will try to run a few times and then disable.
The following are current behaviors that are listed as defects -
1) If you cancel a job that is in the "Queued" state. This will disable that schedule. As @JohnBell pointed out, if you cancel a job that is "running" it will not disable the schedule.
2) You get a OwnerApplicationAccessRevoked under LastErrorCode in the AS_Schedules table in the Mongo. If the user enables the schedule and within 5 minutes the schedule becomes automatically disabled, this is a good indication that the issue is part of another defect. As a note, this occurs with Window Auth Server setups.