SecurityInsights: Old Workspace ID Persisted for a period in backend after recreation of workspace with same name

API Specification is 2021-10-01-preview, also present in previous preview versions

An issue occurs when deleting and recreating a workspace under the same name, where creation of new alert rules from Sentinel onto a workspace presumably does a workspace ID lookup and comes back with an ID of the previously deleted workspace

Example POST:

id: "/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.OperationalInsights/workspaces/workspacename/providers/Microsoft.SecurityInsights/alertRules/alertId"
kind: "Scheduled"
... snipped
type: "Microsoft.SecurityInsights/alertRules"

Example response:

```
{"error":{"code":"BadRequest","message":"Failed to run the analytics rule query. Log Analytics workspace '{old workspace id}' could not be found."}}
```

In my example, I have just deleted a previous workspace titled "workspacename" and created a new one, with the same name. The previous workspace had a workspace id of {old workspace id}, the new workspace has a different workspace id.

For some reason the backend does not refresh or caches the old workspace id's for lookup purposes and does not refresh them until after a while, even when using the permanent deletion feature of a workspace. This is generally annoying when rebuilding workspace in CI/CD testing capacity.

In addition other odd behaviour occurs, some alerts, incidents and automation rules still persist onto the new workspace. Rules that are not scheduled/NRT or are created in a disable state appear to work fine implying its happens during the lookup of the workspace when a rule is enabled to trigger its first run or along those lines.

I haven't tested the exact time period (its likely a few hours?) but definitely by a few days workspace and rules show back blank again

No source file or test is named. Start with the SecurityInsights 2021-10-01-preview specification and reproduce the delete-and-recreate workspace flow, then compare alert-rule behavior using the old and new workspace IDs. Done would require confirming that recreated workspaces resolve to the new ID and that stale rules or incidents no longer persist.

Written by the indexing model from the issue text.