tracker issue : CF-3148753

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

Chained Task creation inconsistencies

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 03/25/2012

Components: Scheduler

Versions: 10.0

Failure Type:

Found In Build/Fixed In Build: Public Beta / 292925

Priority/Frequency: Normal / Some users will encounter

Locale/System: English / Win All

Vote Count: 0

Listed in the version 2016.0.0.297996 Issues Fixed doc
Verification notes: verified_fixed on September 06, 2019 using build 2016.0.01.298513
<cfschedule’s startdate/starttime/interval attributes were required for action="update" pre-CF10.  Omission of all 3, in CF10, creates a Chained Task.

The issue arises when just one or two are omitted.  Here’s what happens in every combination:

1a) (good) When startdate/starttime/interval are all omitted, then all default to [empty string] and chained task is created

1b) (good) When only startdate is omitted, and interval is numeric, then startdate defaults to now() and task is created normally
1c) (bad)  When only startdate is omitted, and interval is non-numeric, then NumberFormatException is thrown (w/ an unhelpful message: ’For input string: "IntervalValueHere"’)

1d) (good) When only starttime is omitted, and interval is not ’once’, then starttime defaults to [empty string] and chained task is created
1e) (bad)  When only starttime is omitted, and interval is ’once’, then NumberFormatException is thrown (w/ an unhelpful message: ’For input string: "once"’)

1f) (bad)  When only interval is omitted, then IntervalNotSpecifiedException is thrown

1g) (bad)  When only startdate or starttime is specified, then NullPointerException is thrown
1h) (good) When only interval is specified, then startdate/starttime default to [emtpy string] and chained task is created

This is too confusing!

The behavior should simply be:
2a) if interval is supplied, then startdate and starttime default to now()
2b) if interval is not supplied, then chained task is created

CF9 required startdate and starttime.  Thus, the fact that startdate defaults to now(), in one specific scenario, must’ve been someone’s ER that was granted for CF10?

Let’s simplify and get some consistency here :)

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

Watson Bug ID:	3148753

External Customer Info:
External Company:  
External Customer Name: itisdesign
External Customer Email:



Related thread:
Comment by External U.
19910 | March 25, 2012 05:24:29 AM GMT
We will be fixing the NullPointerException for now. The other fixes to bring consistency can be done in the next release.
Comment by Himavanth R.
19911 | March 26, 2012 02:41:20 AM GMT
Very cool Himavanth, thanks!
Comment by External U.
19912 | March 26, 2012 02:49:55 AM GMT
None of the issues mentioned here are critical and therefore we will defer it for the next release
Comment by Rupesh K.
19913 | March 26, 2012 03:08:18 AM GMT
Cool, I agree they aren't critical. Just filed it for whenever. Thanks Rupesh!
Comment by External U.
19914 | March 26, 2012 03:45:21 AM GMT
1b, 1e,1f and 1g now throw proper exception with explanatory message. Few other changes can cause backward compatibility issues Chained tasks are like jobs which will get triggered by some external action (like sending an email once some report is generated). As such it does not make sense to associate starttime/date with them. So if user specifies startdate/time, we assume he is creating a non-chained task, hence he has to provide interval also
Comment by Uday O.
19915 | November 20, 2014 01:26:09 AM GMT
Hi Uday, By "1b", I assume you meant "1c" (b/c 1b did not throw an error, but 1c did throw error). Regarding 2a: Interval doesn't make sense for chained tasks. Thus, if interval is specified, then user is creating a non-chained task. In this case, startdate and starttime can default to now. Right? Thanks!, -Aaron
Comment by External U.
19916 | September 28, 2015 03:46:02 AM GMT
Hi Adobe, I've verified this is fixed in CF2016 Update 1 (build 2016.0.01.298513). Thanks!, -Aaron
Comment by Aaron N.
31291 | September 06, 2019 03:36:43 AM GMT