There is a race condition in Identity Broker that could cause incorrect deletes on adapter delta imports.
Imagine I have done an Import All on a connector which returned 20 changes.
I immediately follow with a clear all operation, which clears the connector and adapter context, as well as any processed changes.
Imagine that 10 changes have not yet been processed (possible with very large change sets).
These changes will then be picked up by the change processor, and registered as changes.
If I follow up with a Delta import from FIM, IDB will calculate these 10 orphaned changes as deletes.
We can handle the currently unprocessed changes by clearing the remaining untouched changes.
For the changes in memory, either the count of changes processed on each cycle will need to be throttled, or a conditional might be added to wrap each cycle, or this potential race condition might just need to be highlighted on the UI/documentation.
Customer support service by UserEcho