# Recovering from a shared-hub collision

1. Stop every unrelated worker that can connect with the old shared SQL identity. Do not rotate the credential while both apps are still processing it.
2. Save the output of `verify-isolation.sql` using the old identity. That is the evidence of the affected hub and unfinished work.
3. Run only the application that owns each remaining orchestration type with the old identity, long enough to drain or explicitly terminate its instances. A new identity cannot see this old hub.
4. Create one SQL login/user per application with `provision-runtime-identities.sql`. Put the credentials in the deployment secret store; do not put them in source or manifests.
5. Deploy one app at a time. Before enabling traffic, execute the first query in `verify-isolation.sql` through its runtime connection. Record the returned `EffectiveTaskHub` in the release record.
6. Start a known orchestration in each app. Query `dt.Instances` as an administrator and prove that its row lands under the expected TaskHub.

Do not change `TaskHubMode` as a shortcut. Changing it changes how all existing rows are addressed and makes the current hubs appear empty.