Source Delete Issue, terminated but not really deleted

I delete one source “mySource” from UI, it shows no error. And I can not see “mySource” in the source search result.

However, later when I try to create a new source with the same name through either API or UI, it show me the error: Source with internal name "mySource [source]" already exists.

I do the search api call with the name “mySource”, no result return.
When I do the get source using previous source id, I do get a result. In the result, the name filed is like “Terminate-mySource -1722563457020”, and connectorAttributes.status is showing “sourceStatusDeleting”. Not sure how this happened. I’ve also checked there’s no pending tasks.

How can I get rid of this terminated source? It’s been like this for quite a while.

https://***.api.identitynow.com/v3/sources?filters=id%20eq%20%229289c6806b0040eaa686125665900f57%22

this returns me empty json list

However, when I use this direct get https://***.api.identitynow.com/v3/sources/9289c6806b0040eaa686125665900f57
I do get the source object.

Why there’s a discrepancy here between the above 2 api calls with the same id

Hi @ywu11 ,

Try to delete again using this API delete-source | SailPoint Developer Community

Thank You.

Hi @gogubapu , thanks for replying. This is what I have tried already.

This API only returns a Accepted status code 202, with a body like

{
    "type": "TASK_RESULT",
    "id": "b0542584da8b4d1dafe2ccb4d2c91a71",
    "name": null
}

And after a while, long after a normal delete could be completed, when I use the GET Source API with the source id, I can still see the source returned in response.

I think somehow my source might be stuck in a weird status.

Hi @ywu11 ,

I suggest you to wait for the default purge task to take place and then check for the source. Usually there is a default purging of objects that takes place every night around 10 PM or 10 30 PM. May be check after that.

Thanks,
Shailee

Hi, we have passed by this some times with several clients. Some times something gets stuck and source can not be deleted. What we do is to open a case with Sailpoint and they remove the source.

@shaileeM Thank you. I’ll keep watching it. The 10 PM/10:30 PM is based on what time zone?

What does this default purge task exact do? To remove all ghost objects like this?
It would be nice to understand how this got happened in the first place so we can avoid it in the future.

Here was what I exactly did. I tried to deprecate a source and use the same name to create a new source. So I did

  1. Rename all the access profiles associated with this source to $originalAccessProfileName + "(deprecated)"
  2. Rename the source name itself to ``$originalSourceName + “(deprecated)”`
    At a later timepoint,
  3. delete all deprecated access profiles, and then
  4. delete the source itself.

All seems went well without issue, unless later when I try to create a source with original source’s name, and it says already exists. But again, can’t see this source in ui, only GET Source API with original source id can see it.

thanks for replying. Just wondering if the issue you faced is the same one as what I’m facing.

We did face different issues when delete source, at that time, no matter using ui or api call, it says delete failed immediately, and the reason it says is due to some pending tasks. That solution is relatively straightforward, which we need to find the pending task, and terminate those pending tasks first. Then delete source will work.
But here, I don’t see any direct error message either in ui, or api call at the moment of deletion operation.

Yes, I think it is the same message. I have seeing it also when renaming some source. In this case I saw that renamed source does not change this “internal name [source]”

1 Like

Yeah, that’s weird. I always think the id should be the only real key for any object, but looks like the internal name [source] is also a field acting like the key?

@jsosa in your case, do you see delete operation shows success, but the source failed to get deleted ?

Today’s purge is completed. I can still retrieve this terminated source.

Also, another source I delete today, went through the same situation. And for the one I deleted today, it was just a deletion using the API call. There’s no renaming or any other operations before deletion.

Wondering if all the future source deletion will go through this same pattern.

Hi @ywu11 , this seems strange.

Its worth opening a support case and check on the tenant

1 Like

We also had experienced this issue, mostly on those sources which has a lot of accounts and entitlements data (for e.g., 100k accounts and 200k entitlements).
There’s no other alternate method than creating a SailPoint support ticket to clean-up this source, as mentioned in above posts.

To avoid this happening in future, SailPoint recommends to reset your source before deleting the source.

HTH!

2 Likes

Thank you for replying.
For us, the source really don’t have a large number of accounts, nor entitlements. (~50 entitlements, ~300 accounts)

Also, it looks like the reset source api is deprecated and removed. Only this reset entitlements on a source is what I find reset-source-entitlements | SailPoint Developer Community
Is this the api call recommended by SailPoint ?

Hi @ywu11 ,

Please take a look at this post - POST /api/source/reset/ - Identity Security Cloud (ISC) / Non-Public API Deprecations - SailPoint Developer Community

The replacement API for /api/source/reset/ is yet to be announced.

To reset the source, you will have to reset the entitlements and also reset all accounts. But this will not help to reset the entire source i.e. names etc.

  1. To reset all entitlements on a source, use reset-source-entitlements | SailPoint Developer Community .
  2. To reset all accounts on a source, use delete-accounts-async | SailPoint Developer Community
  3. After resetting entitlements and accounts, you can try to delete-source | SailPoint Developer Community

Hope this approach works for you.

Thanks,
Shailee

@shaileeM

Thank you for replying. So you mean by calling those reset source entitlements and delete accounts first, before calling the delete source api, should ensure the delete is complete and successful?

If so, we will try with this approach in future when we need to delete source again.

We have raised a sailpoint support ticket as well.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.