Concurrent team-member removal and retry operations can return failures after successful removal

[Ridanshi]

Summary

Team-member removal operations are not idempotent.

When removal requests are retried or executed concurrently, later requests can fail despite the desired state already being achieved.

Affected Files

• teamService.ts
• team.ts

Root Cause

The removal workflow assumes the target membership exists at execution time.

Concurrent requests can remove the membership first, causing subsequent requests to return errors even though the user is already removed.

Reproduction

1. Remove a team member.
2. Trigger a retry of the same request.
3. Observe the response.
4. Repeat with concurrent removal requests.
5. Observe failure responses despite successful removal.

Expected Behavior

Removal operations should be idempotent.

Repeated requests should succeed if the target state has already been reached.

Actual Behavior

Later requests fail even though the membership is already removed.

Why This Is Difficult To Detect

Most testing executes a single removal request.

The issue appears only with retries and concurrent execution.

Production Impact

• False failure responses
• Confusing user experience
• Retry instability
• Operational inconsistency

Suggested Fix

Treat already-removed memberships as successful outcomes and introduce idempotent behavior.

Severity

Medium-High

[Ridanshi]

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

The current team-member removal workflow appears to treat already-completed removals as failures.

I plan to:

• review membership removal behavior
• introduce idempotent handling where appropriate
• preserve existing authorization checks
• add regression tests covering retries and concurrent removals

Please assign this issue to me.