Discussion:

When it comes to inserting a device into a collection App Portal will happily insert indefinitely if a failure occurs during an insert. When an error occurs during an insert App Portal will change the insert date on the request to an hour in the future and then try it again. It will keep doing this over and over. 

The scenarios that usual cause an insert to fail are:

1) The device no longer exists in SCCM. This would usually happen if say you enabled a lease for like two years. In the two year period the device no longer exists. When the lease is up and App Portal tries to reclaim the software this will cause an error. Similarly if an approval is not approved for a very long time and in that time the device does not exist the same thing would happen when approved.

2) The target collection is missing in SCCM. This usually happens when someone inadvertently deletes a collection in SCCM instead of going thru App Portal to archive or delete the catalog which cleans up the collections the expected way.

3) Someone has enabled uninstallation of a catalog but has not added an uninstall deployment to that catalog. Someone would submit the uninstall request, even thought there is no uninstall deployment.

Now when a single insert fails that is not going to cause any harm it is when a large number of failed inserts happen that actually breakage or slowdown can occur.

App Portal will try to insert a set amount of devices, "X", in each insert iteration. "X" is set in the database. If the amount of bad inserts is bigger than "X" then "good" inserts will never get processed because the bad inserts have clogged up the inserts .

By default this  size of "X" is set to 100. If all 100 spots  are clogged by bad inserts then this number can be increased so that inserts can continue. To update  the size of "X" use the query below and change the value to whatever size you need:

Update WD_AppSettings set value = '200' where keyname = 'RequestProcessingBatchSize'

Do not increase the size beyond 200, as IIS will Likely reject the large dataset, or simply time out..

After doing this inserts should continue since there are now more slots for "good" inserts.  After you have updated this number we would recommend cleaning up the "bad" inserts. You can do that by canceling the offending requests using a query similar to the one below:

UPDATE WD_PackageRequests SET IsLeased = 0, LeaseExpire = NULL, Deleted = 1, Inserted = 0, InsertDate = NULL, monitor = 0 WHERE requestID in ( 1, 2, 16, etc.)