We aren't able to retrieve our closed update sets in test-instance from our development-instance

[dirkdp]

Good afternoon,

We aren't able to retrieve our closed update sets in test-instance from our development-instance.
 

We get the following message:
Retrieving update sets updated after 2025-05-26 from Development (https://ourdevelopment.service-now.com)

 Pending 0%

Job is not in the queue yet

Test connection to our update source is OK

Already looked at

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

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0718606
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0780720
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0535176

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0966213 - not relevant

Even changed the system property glide.update_set.retrieve_days to 0 (zero) for a test

What can be the problem?

Thanks!

[Mark Manders]

Since it's showing 0%, it's not that there's nothing there or the update sets already exist. 

Log a case with NowSupport. They can see more than you can and way more than we can. 

[YaswanthKurre]

Hi @dirkdp ,

Check for Stuck Jobs

• Navigate to System Scheduler > Scheduled Jobs.
• Look for jobs related to update set retrieval.
• If any are stuck or failed, try deleting and re-triggering the retrieval.

Check the sys_trigger Table

• Go to sys_trigger.list and filter for:
  • name contains RetrieveUpdateSets
  • state is not complete
• If the job is not there, it means the retrieval job was never queued — possibly due to a script or permission issue.

or better raise a support case with ServiceNow.

Mark this as helpful and correct if this resolved your issue.

Thanks,

Yaswanth.

[GlideFather]

Hi,
Let's find out whether it is a problem with one particular update set or all of them.

If just one (or a few): You can try to export the update set to XML and import it using the Retrieved Update set module.

Similar behaviour can happen when an update set is committed and then backed out for example (let's not talk about the backing out being a good idea or not for now), in that case the export could do the trick.

If all or more update sets, then try to raise the HI ticket.

[GlideFather]

Eventually navigate to the [sys_mutex] table and search for "update-mutex" record, if needed you can delete it from there.

This was a method that helped me when it was stuck in the middle of the process (sorry not remember if it was loading, previewing or committing - just could not continue)