Limit stealing of URNs between contacts

[rowanseymour]

We've had a few problems recently with users not realizing that if you add a URN to a contact in a flow, and that URN already exists.. it's "stolen" from the other contact, potentially leaving an empty unaddressable contact. The UI and API don't allow this and report as an error that the URN is already taken. Bit of a footgun.

We could remove this is as a possibility or make it optin on the action - either way this isn't a split so we would just generate an error event in the case that the URN is taken.

The original usecase for being able to steal was allowing merging of contacts.. maybe that needs to become more of an explicit thing?

[github-actions]

Without activity, this issue will be closed in 14 days.

[rowanseymour]

To do this right - the action to update a URN would have to become a split. If the URN can't be assigned because it's already taken then the flow takes the Failure exit. If it can, the flow takes the Success exit and the URN state is changed in the engine context.

We could pass a URN service to the engine which is implemented in mailroom to do the db change.

• Something like URNService.Assign(contact *flow.contact, urn urns.URN) error
• There might still be a contact_urns_changed event but it wouldn't make any further changes.
• The service will be making the db change prior to the transaction used to commit db changes from events.. which I think means we avoid deadlocks.