topic Re: What causes schedules to "Disable"? in Alteryx Server Discussions

What causes schedules to "Disable"?

Claje — Thu, 15 Nov 2018 14:22:00 GMT

Hi,

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?

Re: What causes schedules to "Disable"?

rahuls — Tue, 27 Nov 2018 04:23:43 GMT

Hey @Claje,

Any luck on this issue? I am also facing this in the gallery scheduler. Some of the workflows go 'disabled' from time to time.

Re: What causes schedules to "Disable"?

MichaelF — Thu, 29 Nov 2018 17:49:47 GMT

Hi @Claje @rahuls

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 support@alteryx.com and explain the situation best you can.

Cheers,

Mike

Re: What causes schedules to "Disable"?

Claje — Thu, 29 Nov 2018 21:04:53 GMT

Thanks for this information!

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.

Re: What causes schedules to "Disable"?

rahuls — Fri, 30 Nov 2018 04:53:06 GMT

Thanks @MichaelF @Claje,

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?

Best,

Rahul

Re: What causes schedules to "Disable"?

JohnBell — Fri, 30 Nov 2018 17:29:23 GMT

Hi,

My observations:

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.

Hope this helps,

JohnBell

Re: What causes schedules to "Disable"?

MichaelF — Fri, 30 Nov 2018 19:53:21 GMT

Hi @Claje @rahuls @JohnBell

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.

Cheers,

Mike

Re: What causes schedules to "Disable"?

JohnBell — Fri, 30 Nov 2018 21:07:10 GMT

Just to be pedantic...

In regards to the previous statement: If you cancel a job that is in the "Queued" state. This will disable that schedule. ….

In my experience, going thru the Admin Gallery..."State" of workflows...there are 3 states 1) Active 2) Completed 3) DISABLED

If you cancel a job that is in the "Queued" state; yes, it will become "disabled", but it will appear as "Completed" in the "State" field.

Re: What causes schedules to "Disable"?

rahuls — Mon, 03 Dec 2018 04:48:25 GMT

Thanks @MichaelF,

This is a really good summary. Really appreciate it.

Re: What causes schedules to "Disable"?

MLan — Tue, 28 May 2019 04:11:56 GMT

My schedule was disabled and the error message was that the username or password was incorrect. However that was not the case and all I did to re-enable the schedule was to click the 'Enable this schedule' tick box and it has worked again.

Re: What causes schedules to "Disable"?

Kethan_Patel — Mon, 09 Sep 2019 20:49:55 GMT

This is a know issue and it has been fixed in Version 2019.2.7.63499.

Re: What causes schedules to "Disable"?

davidhenington — Tue, 28 Jan 2020 00:55:07 GMT

This appears to be back with newest version. 2019.4.6.21113.

Scheduled workflows flipping to disabled with no rhyme or reason on multiple artisans.

Re: What causes schedules to "Disable"?

davidhenington — Tue, 28 Jan 2020 18:57:51 GMT

Update: this appeared to have started occuring when one user shared several workflows to our internal "public" studio.

Suddenly only the workflows that were shared retained their schedules.

Very odd!

Re: What causes schedules to "Disable"?

thedr9wningman — Mon, 03 Feb 2020 17:50:51 GMT

I've re-ticked that box about 100 times. In my environment, it is still shutting off the re-scheduled jobs within 5 minutes. And my customers are not happy about this.

Re: What causes schedules to "Disable"?

thedr9wningman — Mon, 03 Feb 2020 17:55:18 GMT

I work in the same environment as @davidhenington and want to confirm that this is an issue. I have tried multiple means to test and fix this issue and the only fix I have that currently keeps my jobs scheduled is moving the scheduled workflows to the Public Gallery within our corporate instance of Alteryx Gallery.

I hope this band-aid helps others in the future; it makes the public gallery a little polluted, and has a security problem in the sense that anyone can run your workflows, but I'm lucky enough that I have had minimal user-input in my scheduled workflows and they cannot choose where the outputs go (and therefore have access to data that they don't need access to).

Bonus learning: I was able to turn off the 'download this workflow' option in each workflow's page on Gallery under its icon in Workflow Settings.

Re: What causes schedules to "Disable"?

thedr9wningman — Mon, 03 Feb 2020 17:59:32 GMT

@MichaelF
Question: When you say:

"😎 If credentials are expired, Scheduler will try to run a few times and then disable."

Which 'credentials' are you talking about? Windows credentials? Credentials to log into Gallery? Credentials for the workflow itself?

This issue is plaguing me and I'm trying to get to the bottom of it, but I'm having a hard time figuring out what piece of the (very complex) puzzle needs fixing.

Re: What causes schedules to "Disable"?

Kethan_Patel — Mon, 03 Feb 2020 18:03:22 GMT

Can you add the user explicitly to the permission tab?

That's the fix Support have provided in the past and it works.

Re: What causes schedules to "Disable"?

wildflower — Mon, 17 Feb 2020 17:11:59 GMT

@davidhenington Do you happen to have a workaround? We're on 2019.4.6. A public workflow in our studio has a schedule set up by an end user (an Artisan) outside of our studio and it decided to revert to disabled last Friday. Workflow and schedule hasn't been touched in 4 months. I'm in the Admin page and when I go to edit the schedule to re-enable it, I only have these options. This prompt is not true, it's a public workflow... No, Alteryx, I don't want to delete it.

Re: What causes schedules to "Disable"?

thedr9wningman — Mon, 17 Feb 2020 20:10:10 GMT

Hi @wildflower

I worked with @davidhenington when he was at the company we worked together on. He is, unfortunately, no longer with the company. I remain, though.

The public workflow option was our workaround. That is my current workaround for ensuring that the disable dialogue isn't happening.

My best recommendation is to ensure that the workflow is indeed in the (local) public gallery. Any changes made to the permissions of the gallery association has, at least for me, resulted in the automatic disabling of the workflow.

We have one colleague here who is able to share it to a new collection he created and those workflows are stable. The collection was built after the server was upgraded to 2019.4.6. I tried to mimic that behaviour and could not get the same results. For our environment, the only thing I can get to work is publishing the workflow to the public gallery. Its membership in collections or private studios has no apparent bearing on whether it is auto-disabled or not, as long as it is in the public gallery. As soon as I take it off public, it auto-disables.

Although I hear you that the workflow/schedule hasn't been touched in 4 months (which frightens me), I still recommend re-upping the gallery membership for that workflow into the public gallery. I'm super curious as to the seemingly random behaviour of this particular bug.

Best of luck. We seem to need it right now. This issue has been lingering a month or more and I have no hope or inkling that it will be fixed soon.

Re: What causes schedules to "Disable"?

wildflower — Tue, 18 Feb 2020 17:46:52 GMT

Thank you for the suggestion, @thedr9wningman - making all of our ETL workflows public isn't an option for us as there are sprocs, SFTP, and email rendering we don't want the rest of the company to accidentally run.

I did some digging and want to provide more detail on the error screenprint I posted: It's definitely a BUG with server 2019.4.6. I queried MongoDB and found the workflows that used to reside in one studio are now in another studio. That's the reason for the error, the workflows are no longer in the studio where the publishers are still members of. This then causes the schedules created in that studio to break (Disabled). We create studios for departmental teams. I had moved one user no longer part of a team out of that team's studio into another studio - this user did not publish any workflows to the gallery however, all workflows in the original studio moved with that user during the Subscription edit. This is a huge inconvenience and we'll most likely have to make manual edits in our MongoDB.

Our workflows must remain private for security protocol. I could create collections as a workaround but would rather the bug be fixed! I've initiated a case with Support.

Screenprint mentioned: Error loading schedule.The workflow this schedule uses is no longer available to this user. Do you want to delete the schedule?