Skip to main content

Why objects can’t upgrade (ServiceNow)


ServiceNow unable to revert an object to baseline during an upgrade - presented with an error

When a hotfix was provided on a protected script for example

look at the hotfix update set to check if the Replace on upgrade flag is set to true for that file in the update set?  If it is set to false it can cause this issue.  If it is false change the flag in the update set to true which should allow the file to be reverted to the baseline, release version.



Just setting the flag in the already-applied update set seems to do the trick

---
Additional info (via ServiceNow Support):

vSOLUTION PROPOSED: 

After analysing the logs at the time of the upgrade,  we saw that the objects was loaded but the version was not added since it is a duplicate of the latest existing ones.

Example for sys_script_include_d026e995472f95d4207ddfbd436d43cf :

2026-03-19 23:07:23 (694) worker.1 worker.1 txid=e862f2ec87fb ESLatestScriptLoader Skipping sys_es_latest_script record because there is an existing record with table = sys_script_include and id = d026e995472f95d4207ddfbd436d43cf
2026-03-19 23:07:23 (724) worker.1 worker.1 txid=e862f2ec87fb VersionWriteRepository Version was not added, it is a duplicate of the latest existing one: sys_script_include_d026e995472f95d4207ddfbd436d43cf/AccessRequestProbe

Normally the Issue linked to payload of the current sys_update_version record of the file that was exactly same as the payload of the file in the sys_upgrade_history _log table. So the incoming file in the installation exactly matched the current version.When comparing the current version with the historical version, the current version looks the same.

You have  confirmed that you  have the correct versions in use for all affected records so the issue is resolved from a functional perspective.

In regards to how this logic works, we can explain from the information we have in the logs which shows that they are being treated as a duplicate. The platform tells us as much "Version was not added, it is a duplicate of the latest existing one" So, in typical behaviour a sys_update_version is not added. Nor would it replace the existing version (sys_update_version) from being current. In such a scenario, update sets have precedence over store application inserts. Update set additions at this level are considered customizations, which need to be protected. The protection being "replace on upgrade". Regardless of whether it is protected or not, the version will not be added if it is considered a duplicate. To conclude this is the expected behaviour and how it works. The "current" will not become the store application version that was offloaded.
Labels:

Comments

Post a Comment

Popular posts from this blog

ServiceNow check for null or nil or empty (or not)

Haven't tested these all recently within global/local scopes, so feel free to have a play! option 1 use an encoded query embedded in the GlideRecord , e.g.  var grProf = new GlideRecord ( 'x_cls_clear_skye_i_profile' ); grProf . addQuery ( 'status=1^ owner=NULL ' ); grProf . query (); even better use the glideRecord  addNotNullQuery or addNullQuery option 2 JSUtil.nil / notNil (this might be the most powerful. See this link ) example: if ( current . operation () == 'insert' && JSUtil . notNil ( current . parent ) && ! current . work_effort . nil ())  option 3 there might be times when you need to get inside the GlideRecord and perform the check there, for example if the code goes down 2 optional routes depending on null / not null can use gs.nil : var grAppr = new GlideRecord ( 'sysapproval_approver' ); var grUser = new GlideRecord ( 'sys_user' ); if ( grUser . get ( 'sys_id' , current . approver )){...
Post a Comment
Read more