improvement(oauth): added random identifier in unnused accountId to bypass betterauth unique constraint

[waleedlatif1]

Summary

• added random identifier in unused accountId to bypass better-auth unique constraint
• we don't use accountId, but better-auth enforces unique id so we can just append a randomUUID to it
  • this prevents account_already_linked_to_different_user issue

Type of Change

• Bug fix

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
docs	Ready	Preview, Comment	Jan 14, 2026 4:58am

[greptile-apps]

Greptile Summary

This PR resolves the account_already_linked_to_different_user error by appending random UUIDs to OAuth account IDs and adjusting the database unique constraint. The previous implementation failed because better-auth enforces a unique constraint on the account id field, which was set to the provider's account ID. When users reconnected or linked accounts, this caused conflicts.

The solution has two parts:

• Random UUID suffix added to accountId in all 19 OAuth providers (GitHub, Wealthbox, Redtail, HubSpot, Salesforce, X/Twitter, Confluence, Jira, Airtable, Notion, Reddit, Linear, Dropbox, Asana, Slack, Webflow, LinkedIn, Zoom, Spotify, WordPress)
• Database unique constraint changed from (userId, providerId, accountId) to (userId, providerId) to allow the random accountId values while still preventing duplicate provider connections per user

The account.create.before hook at lines 150-202 in auth.ts continues to handle reconnection logic correctly by querying for existing accounts using (userId, providerId) and updating them instead of creating duplicates.

Confidence Score: 5/5

• This PR is safe to merge with no identified issues
• The implementation correctly addresses the previous review feedback by adjusting the database constraint to match the application logic. The random UUID approach successfully bypasses better-auth's internal unique constraint while maintaining proper duplicate prevention through the (userId, providerId) constraint. The hook logic remains intact and functional.
• No files require special attention

Important Files Changed

Filename	Overview
apps/sim/lib/auth/auth.ts	appended random UUID to accountId across all 19 OAuth providers to bypass better-auth's unique constraint on id field
packages/db/schema.ts	updated account table unique constraint from (userId, providerId, accountId) to (userId, providerId) to support random accountId values
packages/db/migrations/0140_fuzzy_the_twelve.sql	drops old unique index on (userId, providerId, accountId) and creates new index on (userId, providerId)

Sequence Diagram

sequenceDiagram
    participant User
    participant BetterAuth
    participant OAuth Provider
    participant DB
    
    User->>BetterAuth: Connect OAuth Account
    BetterAuth->>OAuth Provider: Initiate OAuth Flow
    OAuth Provider-->>BetterAuth: Return Profile Data
    Note over BetterAuth: Append random UUID to accountId
    
    BetterAuth->>DB: Query existing account by userId and providerId
    
    alt Account exists
        DB-->>BetterAuth: Found existing account
        BetterAuth->>DB: Update account tokens and accountId
        Note over DB: Unique constraint on (userId, providerId)<br/>prevents duplicates
    else Account does not exist
        DB-->>BetterAuth: No existing account
        BetterAuth->>DB: Insert new account with random accountId
    end
    
    DB-->>BetterAuth: Success
    BetterAuth-->>User: Account connected

Loading

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[waleedlatif1]

@greptile