Scheduled Hierarchical Imports post-import script outcomes during node restart - Support and Troubleshooting

Scheduled Hierarchical Imports post-import script outcomes during node restart .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 1. Overview This article extends the behavior described in KB0870543 by addressing a specific and important nuance: the distinction between how the platform handles scheduled job threads versus user threads during an application node restart, and the downstream consequences this has for post-import scripts and chained import set execution.

Understanding this distinction is critical for architects and administrators designing import chains that depend on post-import script logic to trigger subsequent imports in a sequence.

2. Thread Classification in Scheduled Data Imports 2.1 The Scheduled Job Thread A scheduled data import executes as a scheduled job thread. As documented in KB0870543 , scheduled job threads receive special handling during an application node restart: they are re-queued and re-triggered from the beginning of the job as part of the node restart process. This is by design, ensuring that critical background processes such as data imports and scheduled reports are not silently missed due to infrastructure events.

2.2 The Post-Import Script Thread Post-import scripts operate under a different thread classification. Although a post-import script is logically associated with and triggered by the completion of a data import, the execution of that script is treated as a user thread, not as a continuation of the parent scheduled job thread.

The practical implication of this classification is as follows:

Scheduled job threads - re-queued and re-triggered automatically following a node restart. User threads - abandoned on node restart, with no automatic re-queuing or resumption. The post-import script, despite being invoked deterministically upon import completion, inherits user thread behavior. This means that if an application node restarts while a post-import script is executing, the script will be terminated and will not be restarted by the platform.

3. Why the Platform Does Not Attempt to Recover Post-Import Script Execution A common use case for post-import scripts is analytical or evaluative processing - for example, data quality assessments, CMDB reconciliation checks, aggregation logic, or conditional triggering of downstream processes. These workloads can be memory-intensive.

In scenarios where a node restart has occurred, memory exhaustion during the post-import script execution phase is a known contributing factor to the restart itself. Because of this, the platform deliberately does not attempt to evaluate or automatically re-trigger post-import script logic following a node failure. Automatically re-executing logic that may have contributed to a memory exhaustion event - without any contextual awareness of where execution was interrupted, this would risk repeating the failure condition.

This is expected behavior and is not a defect.

4. Impact on Hierarchical and Chained Import Configurations The thread classification distinction becomes particularly consequential in hierarchical or chained import configurations, as many of our Service Graph Connectors would utilize.

4.1 Expected Failure Behavior If an application node restarts while the post-import script of the first import in the chain is executing, the following outcomes should be expected:

The post-import script is abandoned with no record of progress. The trigger for the next import in the chain is not fired as it was waiting for a return on the post-import script that will never occur. All subsequent imports in the hierarchy do not execute for that cycle of hierarchical import. There is no automatic platform recovery mechanism for this failure scenario, the chain is broken at that link until manual intervention or the next scheduled execution cycle. Unlike the parent scheduled job, which restarts from the beginning following a node recovery, the post-import script does not re-queue. The failure of the chain is silent unless active monitoring is in place.

4.2 Contrast with the Scheduled Job Restart Behavior It is important to note that the parent scheduled import job itself will be re-triggered following the node restart, as described in KB0870543. However, on restart, the job has no memory of its prior execution state. The import will run again from the beginning, potentially duplicating actions already completed during the prior run. The post-import script will execute again only if the import itself completes successfully in the new execution cycle. If the node restart occurred after the import data had already been processed but during the post-import script phase, the re-triggered job will re-process the import data before the post-import script has another opportunity to execute.

5. Best Practices and Diagnostic Guidance 5.1 Design for Observability Rather than relying on post-import script logic to self-manage or self-recover, the recommended approach is to use out-of-box platform mechanisms to track ETL processing state and expose configurable properties within custom import logic. This enables operators to:

Detect where in the chain a failure occurred, using external state tracking rather than relying on in-process memory. Avoid embedding complex analytical processing inline in the post-import script, which increases memory pressure at a phase that is already at elevated risk. Provide configurable debug and tracking properties that can be toggled independently of the import process itself. 5.2 Available Debug and Logging Properties The following platform properties are available to assist with diagnostics during import processing, and should be used in replacement of any logic added to a post-import script for debugging purposes:

glide.import.debug This is the legacy import and transform debug property. It can be scoped within an application namespace so that logging is isolated to the relevant application context without generating system-wide noise. Many product teams have extended this property to also trigger debug output within related script includes, making it broadly useful for tracing import behavior.

Robust Transform Engine (RTE) - Verbose Logging For implementations using the Robust Transform Engine, verbose logging can be enabled at the Transformer level via the verbose option on the Robust Import Set Transformer. This provides additional diagnostic output at the transformation phase without requiring custom scripting.

IRE Input Payload Logging For imports bound to the CMDB, the Identification and Reconciliation Engine (IRE) input payload can be captured using the following platform property:

glide.cmdb.logger.source.identification_engine

Set the value of this property to:

*

This will log the full IRE input payload, which is valuable for identifying the data being processed at the point of failure and for diagnosing identification or reconciliation issues that may have contributed to memory pressure or processing delays.

6. Summary The table below provides the key behavioral differences between thread types during an application node restart in the context of scheduled data imports:

Thread Type : Restart Behavior

Scheduled job thread : Re-queued and re-triggered from the beginning of the job. User thread (post-import script) : Abandoned. Not re-queued. Not automatically restarted. Hierarchical imports triggered in sequence after post-import script : Not executed for the affected cycle. Chain is broken at the point of abandonment.

KB Reference:

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0870543