Duplicate Comments When Customer Replies to Notification

[Satyam123]

Hi All,
I’m encountering an issue where, when a customer replies to an Additional Comments notification email, the same reply is being logged twice on the hr case table.

Has anyone faced a similar issue or know what might be causing this? Any help would be appreciated.

Thanks in advance!

[GlideFather]

@Satyam123 
please navigate to email logs and verify whether the email is sent once or twice, then we will know whether it is one email displayed twice on the form or two duplicate emails sent at the same time both being attached to HR Case..

Please let me know more about this detail

[Shraddha Kadam]

Hello @Satyam123 ,

Check for duplicate inbound actions and check if you used current.update() in scripts like inbound actions and business rules.

[Nick Simonelli]

I believe it's fixed in Yokohama patch 5, but I believe this is the issue you're talking about:  https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1923828

Just in case the article updates / disappears for some reason, and I really dislike when people only post links as answers, here is the current content of the article: 

Description

After upgrading to Washington Patch 6 or Xanadu, the work notes and comments are duplicated under the following conditions:

1. When a comment is added, the sys_updated_on timestamp of the incident becomes one second earlier than the corresponding sys_created_on timestamp of sys_journal_field record.
2. If emails are triggered by the incident update, the loading of sys_email records within the related sys_history_set interferes with the last_update_recorded field in sys_history_set.
3. This interference ultimately causes duplication of the comment when the incident is updated again.

Steps to Reproduce

1. Navigate to sys_email record table and get any record associated to some incident that we will use later, and change the type of the record to something that is not 'sent'. 

var email = new GlideRecord('sys_email');
if (email.get('007dda777fa2121015ba54350d866543')) {
    email.setValue('type', 'send-ready');
    email. update();
}

// email record's sys_id : '007dda777fa2121015ba54350d866543'

2. Just update the history set once, as the above step will set the refresh flag to 'true' :

new GlideHistorySet('incident', 'a623cdb073a023002728660c4cf6a768').getHistory();

// Associated incident record's sys_id: 'a623cdb073a023002728660c4cf6a768'

3. Use the following script to add a comment to the incident such that the corresponding journal record has sys_created_on value 1 second after the sys_updated_on value of incident record

// Add a comment WN 01 to the incident

var inc = new GlideRecord('incident');
inc.get('a623cdb073a023002728660c4cf6a768');
inc.setDisplayValue('comments', 'WN 01');
inc.update();
var incUpdatedOn = inc.getValue('sys_updated_on');

// Set the sys_created_on of journal record to 1 second after the sys_updated_on of incident

var journalUpdateOn = new GlideDateTime(incUpdatedOn);
journalUpdateOn.addSeconds(1);

var journal = new GlideRecord('sys_journal_field');
journal.addQuery('element_id', inc.getValue('sys_id'));
journal.addQuery('value', 'WN 01');
journal.query();
if (journal.next()) {


journal.autoSysFields(false);
journal.setValue('sys_created_on', journalUpdateOn);
journal.update();
}

// Load the corresponding journal record in sys_history_line
new GlideHistorySet('incident', 'a623cdb073a023002728660c4cf6a768').getHistory();

4. The above script will set the sys_history_set.last_update_recorded value to that the sys_created_on value of the above sys_journal_field record.

5. Use the following script to set the corresponding sys_email record type to "sent". This will set the sys_history_set.refresh flag to true

email = new GlideRecord('sys_email');
if (email.get('007dda777fa2121015ba54350d866543')) {
email.setValue('type', 'sent');
email.update();
}

6. Just reload the incident form or probably use the script new GlideHistorySet('incident', 'a623cdb073a023002728660c4cf6a768').getHistory(); to load the email record in sys_history_line. This step will again set the sys_history_set.last_update_recorded to the incident's sys_updated_on value i.e. 1 second before the sys_created_on timestamp of the sys_journal_field record for "WN 01". (Keep the incident form open)

7. Navigate to the tab where incident form is open and add another comment "WN 02". Notice the comment "WN 01" will be duplicated.

Workaround

To resolve the duplication issue:

1. The customer can create the property "glide.history_set.pull_journal_entries_from_journal_table" and set it to true.
2. Go to the record on which duplicate comments are present.
3. Right-click on the banner of the record (lets say INCxyz), navigate to History -> list. It will open the corresponding sys_history_set record for the INCxyz.
4. Delete the opened sys_history_set record.
5. Reload the INCxyz form, it will generate a fresh sys_history_set without duplicate comments.

If the impacted records are in huge numbers, then customers can prepare a list of sys_ids of the affected records and use the following script to delete the corresponding history sets.

var gr = new GlideRecord('sys_history_set');
gr.addQuery('sys_id', 'IN', <list_of_sys_ids>);
gr.query();
gr.deleteMultiple();

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Alternative Solution for WP10+ and XP5+ Releases:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

For customers on WP10 or XP5+ releases, an alternative solution is available.

The property 'glide.history_set.pull_journal_entries_from_journal_table' was introduced to address issues caused by scripts like the one below:

var gr = new GlideRecord('incident');
if (gr.get('57af7aec73d423002728660c4cf6a71c')) {
    gs.info("found incident");
    gr.setDisplayValue('work_notes', 'Comment 1');
    gr.setDisplayValue('work_notes', 'Comment 2');
    gr.update();

When this property is disabled or absent, the system populates sys_history_set and sys_history_line by fetching data from both sys_audit and sys_journal_field. Since the system compares entries from both sources, discrepancies lead to duplication.

In this scenario:

- Two journal records are created with values "Comment 1" and "Comment 2".
- One audit record is created with the concatenated value "Comment 2 Comment 1".
- This results in three records appearing in the history set—two from journal records and one from the audit record.

The recommended fix is to enable 'glide.history_set.pull_journal_entries_from_journal_table', as it was designed to prevent duplicate comments.

Additional Alternative: PRB1826101 and 'glide.split_journal_audit_records':

For those who cannot enable 'glide.history_set.pull_journal_entries_from_journal_table', an alternative solution was introduced in PRB1826101.

By enabling the property 'glide.split_journal_audit_records', the system ensures that sys_audit and sys_journal_field maintain the same number of records, resolving duplication:

- Two sys_journal_field records are created with values "Comment 1" and "Comment 2."
- Two sys_audit records are created with values "Comment 1" and "Comment 2."

Even if 'glide.history_set.pull_journal_entries_from_journal_table' remains disabled, enabling 'glide.split_journal_audit_records' prevents duplicate entries. This can be verified on any instance running WP10+ or XP5+ releases.

Related Problem: PRB1844946