tracker issue : CF-3434100

select a category, or use search below
(searches all categories and all time range)

Updating a task via cfschedule resets task to defaults

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/Fixed

Reporter/Name(from Bugbase): Dave Ferguson / Dave Ferguson (Dave Ferguson)

Created: 12/26/2012

Components: Scheduler

Versions: 10.0

Failure Type: Data Loss

Found In Build/Fixed In Build: Final / 2018.0.02.312829

Priority/Frequency: Major / Most users will encounter

Locale/System: English / Platforms All

Vote Count: 3

If you are updating a scheduled task via the cfschedule tag it is possible for some of the task info to be reset back to default.  For example, if task had an eventhander configured and cfschedule was used to update task but eventhandler attribute was not used then eventhandler would be set to blank.  The eventhandler attribute is just one example as this affects other attributes equally.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3434100

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: fergusondj
External Customer Email:  
External Test Config: My Hardware and Environment details:



@Adobe, cfschedule needs action="create". Issue is b/c action="update" is currently used for both creation -and- updates. This causes confusion and other issues. Thanks!, -Aaron
Comment by External U.
16860 | December 28, 2012 03:09:54 AM GMT
+1, pls add action="create" (action="update" should only update, not create)
Vote by External U.
16871 | December 28, 2012 03:11:34 AM GMT
action="update" also clears the Last Ran timestamp. :(
Comment by External U.
16861 | December 28, 2012 03:12:32 AM GMT
This is by design. As this action re-creates the schedule task. For updating particular attributes of an existing task it is recommended to use admin UI
Comment by Uday O.
16862 | September 30, 2013 07:21:34 AM GMT
How is dataloss by design? If I am just updating one part of the scheduled task I wouldn't expect the entire task to be reset to defaults.
Comment by External U.
16863 | September 30, 2013 08:13:13 AM GMT
This is not acceptable! If it's by design, then it's a bad design decision. <cfschedule action="update"> should not reset existing customized values to their defaults. Unacceptable!
Comment by External U.
16864 | September 30, 2013 08:54:35 AM GMT
see my comment. unacceptable!
Vote by External U.
16872 | September 30, 2013 08:54:47 AM GMT
This will be treated as an enhancement. Perhaps introduction of action='create' which will behave like action='update' and 'update' action will do what you all are expecting
Comment by Uday O.
16865 | October 01, 2013 12:22:45 AM GMT
Yes, probably the scheduled tasks shouldn't have been designed like this. But they have been like this since ColdFusion 5 and changing this behavior would mean that all the applications using cfschedule would break which we can't do. We need to decide a new attribute which will decide whether we should delete the current and create a new or update the existing task. Any suggestion for the attribute name? or any other suggestion?
Comment by Rupesh K.
16866 | February 11, 2014 03:32:10 AM GMT
Hi Uday and Rupesh, Regarding: "This will be treated as an enhancement. Perhaps introduction of action='create' which will behave like action='update' and 'update' action will do what you all are expecting" Perfect. Has an ER been filed yet for CF12 (since CF12 can break backward-compat)? Thanks!, -Aaron
Comment by External U.
16867 | February 28, 2014 01:34:17 AM GMT
Thanks Aaron. We will be re-opening this bug when we start the work on the next version. There is no need to log another E/R
Comment by Rupesh K.
16868 | February 28, 2014 02:08:56 AM GMT
Hi Rupesh, You're welcome. And awesome, thanks! -Aaron
Comment by External U.
16869 | February 28, 2014 05:20:32 AM GMT
Hi Rupesh, I see this ticket is still marked Closed, but I'm guessing work on CF12 has already begun? I would certainly hope so =P Could this ticket please be re-opened? Thanks very much for considering!, -Aaron
Comment by External U.
16870 | January 30, 2015 05:49:28 AM GMT
Hi Adobe, You promised me that I did not need to log another ticket. You said this ticket would be re-opened. You said that 4 years ago! Can you please do what you said and re-open this ticket? Thanks!, -Aaron
Comment by Aaron N.
27728 | May 10, 2018 01:29:19 AM GMT
Hi Aaron , We are looking into this ticket. We can't change the behavior of 'update' action as it will have backward compatibility issue. What name do you suggest for new action : edit, realupdate,fecthandupdate,updatenodelete etc Another way to handle backward compatibility , would be adding a new attribute . <cfschedule action=update *delete*=no> This will not reset properties (new behavior)  <cfschedule action=update *delete*=yes> This will reset (old behavior). This will be default behavior. Please let us know your suggestions.  Thanks, Uday.
Comment by Uday O.
29001 | May 31, 2018 12:34:17 PM GMT
Hi Uday, Thanks very much for the follow-up! I didn't see your reply b/c tracker's email notification system is broken again :/ (@TrackerTeam: can u pls fix?) Its undocumented resetting of unspecified properties isn’t the only action=”update” issue. It also preserves some metadata (like STATUS) but clears other metadata (like LASTFIRE). It’s a dirty update, whose description is misleading and whose use should be avoided IMO. For those wanting the expected behavior of 1) existing metadata preserved and 2) existing properties preserved, I’d propose action=”modify”. And for those wanting an exception to throw if a task already exists, I’d propose action=”create”. I’d use and recommend both of those over the action=”update” spaghetti. I’d prefer not to have an action=”delete” and delete=true which net the same result. Other tags like ldap and the Exchange tags use action=”modify”, so at least that action attribute value has some precedence. Thanks!, -Aaron
Comment by Aaron N.
29002 | June 05, 2018 08:22:13 AM GMT
Hi Adobe, Received this email: ---- Issue - Frequency updated from 'Most users will encounter' to an empty value ---- Who made that change? Please revert to "Most users will encounter"! B/c *anyone* re-saving their task (via CF Admin or cfschedule) can break their task if they're unawares to this bug. Just b/c it's been 6yr since this ticket was created doesn't mean it suddenly _doesn't_ affect most users. Thanks!, -Aaron
Comment by Aaron N.
29916 | November 09, 2018 07:22:30 PM GMT
Hi Adobe, Are you adding action="modify" (for modifying a task) and action="create" for creating a task? The action="update" is a complete mess. No one should use it, IMO. I'd deprecate it eventually, if it were up to me :) Thanks!, -Aaron
Comment by Aaron N.
29950 | November 21, 2018 01:51:37 AM GMT
Hi Aaron, We have added two new actions : CREATE & MODIFY  CREATE will create a fresh new task. If task already exists, it will thrown an error MODIFY will modify existing task while retaining its old values. If task does not exist, it will throw an error The action "UPDATE" remains the same . The fix for this will be available in the next update of ColdFusion 2018.   Thanks,  Suchika  
Comment by Suchika S.
29956 | November 22, 2018 06:55:32 AM GMT
Hi Suchika, Sweet!!!! This will be very helpful, thank you very much!! -Aaron
Comment by Aaron N.
29957 | November 22, 2018 07:02:32 AM GMT
Hi Suchika, Hopefully these are also done?: 1) CF Admin's "Edit Task" page should now use action="modify". 2) CF restart, and action="modify", should now honor LastRan metadata, and not mistakenly misfire a task. If yes to both, then that'd resolve CF-4197250. I will add repro case to CF-4197250. Can you check please? Thanks!, -Aaron P.S. And CF2018's future Admin API should also support action="modify" functionality, right?
Comment by Aaron N.
29958 | November 22, 2018 08:05:00 AM GMT
Hi Aaron, The fix for this bug will take care of :  1) CF Admin's "Edit Task" page should now use action="modify". For 2) CF restart, and action="modify", should now honor LastRan metadata, and not mistakenly misfire a task, I will re-open the bug CF-4197250 Thanks, Suchika
Comment by Suchika S.
29992 | December 03, 2018 10:35:56 AM GMT
Hi Suchika, Sweet!! Thank you very very much!! =D -Aaron
Comment by Aaron N.
29996 | December 04, 2018 05:18:59 AM GMT