Notifications

82 views

Description

The system logs we see the following error:

cmdb_metadata : Found duplicate cmdb_rel_type records with name: Master of::Stack Member of having sys_ids: 357afff213a21300f39f721a6144b076, c8c685710b22130005d90d2835673aa8: no thrown error

Looking at cmdb_rel_type in the Kingston instance, there may be 2 matching records. When looking at an upgraded London instance, there's only one record:
https://<instance>.service-now.com/cmdb_rel_type_list.do?sysparm_query=parent_descriptorSTARTSWITHMaster

A cmdb_rel_type record with sys_id 357afff213a21300f39f721a6144b076 was added to Kingston Patch 8. However, London onwards includes the following: cmdb_rel_type_c8c685710b22130005d90d2835673aa8.

A Kingston Patch 8 or later patch instance that is then upgraded to London ends up with both, which cases the duplicate error.

All instance on Kingston Patch 8 and London, and later should only have 1 record with sys_id c8c685710b22130005d90d2835673aa8 for the Master of::Stack Member type.

Steps to Reproduce

  1. Install a Kingston Patch 8 or later patch instance
  2. Upgrade it to London or later
  3. Check the Relationship Types table, for duplicate Master of::Stack Member records:
    https://<instance>.service-now.com/cmdb_rel_type_list.do?sysparm_query=parent_descriptorSTARTSWITHMaster
  4. Run a payload through the CMDB Identification engine that uses this relationship type, and it will fail with 
    cmdb_metadata : Found duplicate cmdb_rel_type records with name: Master of::Stack Member of having sys_ids: 357afff213a21300f39f721a6144b076, c8c685710b22130005d90d2835673aa8: no thrown error

Workaround

After carefully considering the severity and frequency of this problem, and risk of attempting a fix, it has been decided to not address this issue in any current or future releases. We do not make these decisions lightly, and we apologize for any inconvenience. If you have any questions regarding this problem, contact ServiceNow Technical Support.

The issue exist for instances that upgraded from Kingston Patch 8 and later patches, to London and above.

To fix the issue:-

  • Find any cmdb_rel_ci records using the 357afff213a21300f39f721a6144b076 sys_id cmdb_rel_type record 
    https://<instance>.service-now.com/cmdb_rel_ci_list.do?sysparm_query=type%3D357afff213a21300f39f721a6144b076
  • Update those cmdb_rel_ci records to use the c8c685710b22130005d90d2835673aa8 sys_id cmdb_rel_type record
  • Delete the 357afff213a21300f39f721a6144b076 sys_id cmdb_rel_type record

The following script will do those 3 steps, which can be run as an 'admin' user from the "Scripts - Background" page:

var relGr = new GlideRecord('cmdb_rel_ci');
relGr.addQuery('type','357afff213a21300f39f721a6144b076');
relGr.query();
while (relGr.next()) {
relGr.type='c8c685710b22130005d90d2835673aa8';
relGr.setWorkflow(false);
gs.log('PRB1345146 fix script: Updating cmdb_rel_ci:' + relGr.sys_id,'PRB1345146');
relGr.update();
}
var typeGr = new GlideRecord('cmdb_rel_type');
if (typeGr.get('357afff213a21300f39f721a6144b076')) {
typeGr.setWorkflow(false);
gs.log('PRB1345146 fix script: Deleting cmdb_rel_type:' + typeGr.sys_id,'PRB1345146');
typeGr.deleteRecord();
}

Related Problem: PRB1345146

Seen In

SR - IRM - Audit Management - New York 2019 Q3
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - GRC Workbench - New York 2019 Q3
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3
SR - ITOM - Discovery and Service Mapping - v1.0.35

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-10-07 02:12:26
Published:2019-10-07