Concurrent team-member invite requests can create duplicate membership records and return inconsistent results

[Ridanshi]

Summary

The team invitation workflow performs membership existence checks separately from membership creation.

Under concurrent requests, multiple invite operations targeting the same user can pass validation simultaneously and attempt to create duplicate memberships.

Affected Files

• teamService.ts
• team.ts

Root Cause

The invitation flow follows a check-then-create pattern.

Concurrent requests can both observe that no membership exists and then proceed to create records simultaneously.

The workflow lacks transactional enforcement or idempotent membership creation guarantees.

Reproduction

1. Create a team.
2. Send multiple invite requests simultaneously for the same target user.
3. Observe invite processing.
4. Inspect resulting membership records.
5. Observe duplicate creation attempts or inconsistent API responses.

Expected Behavior

Repeated invites for the same user should be handled idempotently.

Actual Behavior

Concurrent requests can race and create inconsistent membership state.

Why This Is Difficult To Detect

Sequential testing behaves correctly.

The issue only appears under concurrent invite activity.

Production Impact

• Duplicate memberships
• Failed invitations
• Inconsistent team state
• Unexpected API errors

Suggested Fix

Introduce transactional membership creation or enforce uniqueness with safe retry behavior.

Severity

High

[Ridanshi]

I investigated this issue and would like to work on it.

The current invitation workflow appears vulnerable to concurrent membership creation races.

I plan to:

• review invite creation logic
• enforce membership uniqueness under concurrency
• preserve existing invitation behavior
• add regression tests covering concurrent invite scenarios

Please assign this issue to me.