Symptoms

A customer, when attempting to do the final Commit of an Update set that is normally expected to complete without any issues may generate the following error message and not successfully commit the objects on the instance:

Commit called without update set ID

 

In addition, the Update set will usually remain perpetually in a state of Committing.

 

This article will describe the most common cause of this issue and potential troubleshooting methods for when this issue might occur.

Environment

[Optional - include if helpful; remove this entire section if unnecessary]

Cause and Troubleshooting

Although this error is relatively rare, when it does occur it almost always is caused by a running Business Rule which has intentionally executed an abort statement (often through the usage of the setAbortAction(true); Javascript statement a part of a script run from the Script field of the Business Rule).

This may be an unexpected result, as it is not intuitive that the update set would run any specific Business Rules during a commit operation.  The issue arises because, upon commit the Update Set record itself is saved on the instance.  Thus, in turn runs any "On Update" Business Rules that may be configured on the sys_update_set table.  If for any reason that update set executes the setAbortaction() function the commit will be aborted, although no error will generally be displayed on the screen.  Usually with these update sets, the Business Rule was intended for a user intentionally modifying or creating the update set (to prevent the update set from being saved with an invalid name or other field value).  However, since a Business Rule will also run on an automatic, system generated update, this same check will be performed, which, if for any reason causes the setAbortAction() function to be called, the operation will be canceled.

As a normal troubleshooting step for an issue of this type, the localhost logs should be reviewed from each node of the instance to determine if a specific error message is being generated related to the update set action.

For example, the following error message might be found in reviewing the logs at the time which the Update Set commit was attempted:

2019-03-10 18:13:42 (512) worker.0 worker.0 txid=ad730b15db04 Background message, type:error, message: Update set name can only include Alphanumeric, Underscore(_) and Dot(.) characters
2019-03-10 18:13:42 (513) worker.0 worker.0 txid=ad730b15db04 Operation against file 'sys_update_set' was aborted by Business Rule 'Update Set nam9ing validation^a1730b15db40bf043e1badea3b96198a'. Business Rule Stack:Update Set naming validation

Or, in another case, the following might be found in the localhost logs when attempting to commit an update set on an instance:

2019-03-19 08:53:49 (320) worker.4 worker.4 txid=0ccdb44ddb05 Background message, type:error, message: There is already another Update Set with name "Customer Fulfiller - CRM". Aborting update.
2019-03-19 08:53:49 (320) worker.4 worker.4 txid=0ccdb44ddb05 Operation against file 'sys_update_set' was aborted by Business Rule 'Prevent duplicate Update Sets by Name^c0cdb43bdb05bf002f497a3e0f961911'. Business Rule Stack:Prevent duplicate Update Sets by Name

These are usually custom error messages generated in a custom Business Rule which is accompanied by the aforementioned setAbortAction() function call.  However, when the Business Rule is triggered by an automatic save of the sys_update_set record, the Business Rule may not output an actual error message to the logs.  In those cases, the Operation against file 'sys_update_set' was aborted by Business Rule message should still appear in the log files which would also display the Business Rule name and sys_id of the Business Rule that aborted the update set operation, which can then be opened for review.

Resolution

The first step in resolving these issues is to determine the Business Rule that is actually issuing the setAbortAction() command.  This can usually be found, as per the Cause and Troubleshooting section above in the localhost logs corresponding to the error received.  The log data will usually include the Name of the Business Rule as well as the sys_id of that Business Rule which is aborting the operation.

This Business Rule should then be opened for editing and reviewed to locate the command which appears to be aborting the operation.

The Business Rule can be examined to determine what condition is causing the abort action.  Oftentimes, the Business Rule is written with the intent to prevent an update or creation of a Business Rule but not necessarily to be run when the Update Set record is modified automatically due to a Preview or Commit operation.  However, in many cases the issue causing the Business Rule to abort the operation can be corrected.  In the examples from the logs above, the file name was invalid (in the first case containing a specific special character the Business Rule was attempting to prevent or having a duplicate name as another Business Rule already found on the instance).

As a short term fix, the Business Rule that is generating the issue cans be temporarily disabled which would then ignore the Business Rule and allow the Update Set to complete the requested operation (which will, as a result update the Update Set record).  To do this, simply uncheck the Active checkbox on the Business Rule, save the Business Rule and then retry the Update Set operation.  After the update set operation has completed, the Business Rule can then be re-activated.

Another, longer term fix option might be to modify the specific Business Rule associated to that Update Set such that it will not execute this Business Rule when the Update Set record is modified by a Preview, Commit or similar operation.  This can be done either through use of the Conditions statement or directly in the script itself found in the Script field of the record to ignore the functionality in the event of an automated update.

There are generally no out-of-box Business Rules that are triggered against the sys_update_set record on update, but there are third party utilities and specific customer customizations that may introduce such a Business Rule onto an instance.