🐛 Serialise first-login user provisioning behind an advisory lock

[awais786]

Summary

On first-ever SSO login the SPA fires multiple parallel API requests (workspaces, members, …) with no session cookie set yet. Every request reaches `SsoUserProvisioningService.findOrCreateUser`, every request hits the `findOne`→`save` pair, and before the row is committed the others have already passed the `findOne` miss. The losers of the race throw a unique-constraint 500 instead of returning the winner's row.

Same root cause as the Outline incident where a user reported 5 duplicate User rows for one Cognito identity within ~800ms — different fork, same first-login parallel-request pattern.

Twenty's `UserEntity` does have a unique-on-email constraint, but the current code does NOT catch the resulting DB error. The losing requests fail with a 500. The user retries; the same race window reopens.

Fix

Serialise the find+create on a Postgres advisory lock keyed by the email hash. Different emails take different lock keys; concurrent first-logins for distinct users don't contend.

```ts
return await this.dataSource.transaction(async (manager) => {
await manager.query(
'SELECT pg_advisory_xact_lock(hashtextextended($1, 0))',
[email],
);
const userRepo = manager.getRepository(UserEntity);
const existing = await userRepo.findOne({ where: { email } });
if (existing) return existing;
// … create + save under the lock
});
```

• `pg_advisory_xact_lock` is transaction-scoped — released automatically on commit/rollback, no leak risk
• `hashtextextended` maps the email to a stable bigint, exactly what `pg_advisory_xact_lock` expects
• Re-check inside the lock catches the case where another request committed while we waited

Why not just rely on the unique constraint?

Catching `QueryFailedError` on unique violation and falling back to `findOne` would also work — that's the pattern Plane and SurfSense use in the equivalent flow. But it requires the constraint to exist, and it surfaces the race as an error path rather than serialising at the source. The advisory-lock approach:

• Doesn't depend on the constraint (cleaner separation: schema describes data shape, code handles concurrency)
• Doesn't generate a logged error per losing request — the losers wait and read, no failure surface
• Matches the approach used in the companion fix in `Pressingly/outline` (no unique constraint there by design, so advisory lock was the only option). Same code shape across forks.

Tests

Three new tests in `sso-user-provisioning.service.spec.ts`:

• `should acquire an advisory lock keyed by email before find+create` — pins the lock pattern (call shape + parameter)
• `should take the advisory lock before any user lookup` — pins the ordering invariant (lock first, then findOne); guards against a refactor that moves the findOne above the lock
• `should skip create when another request committed a row first` — simulates the race outcome: lock serialises, findOne under the lock sees the winning row, we return it without creating

All existing tests pass unchanged.

🤖 Generated with Claude Code