Identities with custom ID not atomic on the service

[mderriey]

• Package Name: @azure/communication-identity
• Package Version: 1.4.0-beta.1
• Operating system:
• nodejs
  • version: 24.14.1
• browser
  • name/version:
• typescript
  • version: 6.0.3
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://learn.microsoft.com

Describe the bug

When using custom IDs, the service isn't atomic, such that multiple close-enough calls to createUser({ customId }) will produce two separate identities, and subsequent calls will fail with a MultipleIdentitiesForCustomId error.

To Reproduce
Steps to reproduce the behavior:

const client = new CommunicationIdentityClient(endpoint, azureCredential)
const customId = randomUUID()

await Promise.all(new Array(10).fill(null).map(async () => {
  const { communicationUserId } = await client.createUser({ customId })
  console.log('Identity ID', communicationUserId)
}))

Expected behavior

All 10 promises return and log the same identity ID.

Screenshots

N/A.

Additional context

I understand this is not a client library issue, but I figured it's probably the best way to get the engineering team involved. Thanks for your understanding. Please point me in the right direction otherwise.

[github-actions]

🎯 Agentic Issue Triage

Summary: The author reports that concurrent calls to createUser({ customId }) can create multiple distinct identities for the same custom ID instead of returning the same identity. They explicitly acknowledge this is a service-side atomicity issue, not a client library bug.

📋 Issue Details

Package: @azure/communication-identity v1.4.0-beta.1
Affected API: CommunicationIdentityClient.createUser({ customId })
Scenarios:

• Multiple concurrent createUser calls with the same customId create duplicate identities
• Subsequent calls fail with a MultipleIdentitiesForCustomId error

Root ask: The author wants to understand whether this is a known limitation or a bug, and to get the engineering team involved to address the service-side non-atomicity.

🔎 Debugging / Reproduction Notes

The issue is reproducible by firing 10 concurrent createUser({ customId }) calls using Promise.all. The service creates multiple identities for the same customId, which is non-atomic behavior.

Suggested investigation steps:

1. Confirm whether the service is expected to be idempotent/atomic for createUser with the same customId under concurrent load.
2. Check if there is any server-side locking or deduplication for custom ID creation.
3. Investigate whether a retry/backoff pattern on the client side (detecting MultipleIdentitiesForCustomId) could serve as a workaround until the service is fixed.

🏷️ Label Confidence

• Category: Service — the author explicitly states this is not a client library issue; the non-atomic behavior is in the Azure Communication Identity service itself
• Service: Azure.Communication.Identity — the package @azure/communication-identity maps to this service
• Confidence: Low — the most confident category prediction is "Service", which is excluded from automated triage per policy; falling back to needs-triage for human review

👥 Owner Routing

• Matched CODEOWNERS entry: None — label prediction resulted in low confidence (Service category excluded); no CODEOWNERS lookup performed
• AzureSdkOwners: none listed
• ServiceOwners: none listed
• Routing action: Added needs-triage for manual review by the team
• Scan notes: Skipped CODEOWNERS scan because no confident category/service label pair was applied

Generated by Agentic Triage for issue #38531 · ● 172.1K · ◷