Due to the way in which we use GroupShare we now find ourselves with several thousand empty organisations. This leads to a problem whereby the GroupShare web UI takes a long time to load after log-in. However, attempting to delete these organisations via the web UI takes about 30 seconds, during which time the UI is unusable. Furthermore, with each successive organisation-delete request the UI becomes increasingly sluggish. After 5 or 6 organisations have been deleted the UI is pretty much unusable and the user must close the browser tab and open another.

So my next idea was to delete the organisations via the GroupShare REST API. I had a list of around 200 organisation IDs and wrote a small console application which would enumerate this list and send a DELETE request containing each ID to the API. To avoid hammering the API too hard I set these requests to be spaced 2.5 seconds apart.

This worked and the organisations were deleted (only about 5000 more to go).

However, while this was underway - and for the rest of that day - I received repeated notifications from colleagues that GroupShare was not behaving correctly. For example, one colleague sent me a screenshot obtained from the web UI showing a list of 12 TMs in one organisation and another screenshot showing the same organisation opened in Trados revealing only 1 TM. By the next day she couldn't replicate this problem. But mostly the problems were related to accessing organisations, and more specifically asking GroupShareKit for the organisations - for several hours it would almost always respond with a BadRequest response:

Sdl.Community.GroupShareKit.Exceptions.ApiException: An error occurred with this API request - Status code BadRequest

By the next day the problem had gone away.

Here's my working theory: Does GroupShare maintain a cached list of organisation details - just basic details such as the ID and maybe the name? When a request asks for the complete list of organisations this cached list gets enumerated, with the API internally obtaining the details for every item in this cached list. I suspect that deleting an organisation through the API doesn't update the cache (or doesn't cause the cached item to be immediately invalidated) so asking for a list of all organisations causes the API to request the details of a now-deleted organisation... which causes a BadRequest exception, which is the same response I receive if I send a GET request specifying an invalid ID.

Just to be clear, I was deleting the organisations directly via a REST API call whereas the concurrent request-all-organisations request was sent via GroupShareKit.

So is there a safer way to delete a large number of organisations via the API?