fix: allow soft-deleted users to re-authenticate

[tanujbhaud]

Fixes Issue #32 where users who soft-deleted their accounts were unable to sign back in. The re-auth logic was strictly looking for an existingUserId flag which wasn't consistently provided during standard fresh login flows.

Greptile Overview

Greptile Summary

This PR updates the authentication logic to allow soft-deleted users to sign back in by relaxing the requirement for an existingUserId flag during re-authentication, and adjusts tests accordingly to assert on deletedAt directly.

The change affects the core auth flow in convex/auth.ts and its corresponding tests in convex/auth.test.ts, aiming to unblock standard “fresh login” flows that don’t always provide existingUserId while still supporting account reactivation.

Confidence Score: 2/5

• This PR changes core auth reactivation behavior and needs careful identity-matching validation before merging.
• Allowing soft-deleted users to re-authenticate without a consistent existingUserId can be correct, but it raises the risk of reactivating or linking the wrong account unless the code strictly matches incoming identities (provider + subject) to the soft-deleted user record. Without verifying that invariant, this can become an account-takeover class bug in certain provider/identifier scenarios.
• convex/auth.ts (reactivation/linking logic); convex/auth.test.ts (ensure negative tests cover wrong-identity reactivation)

_{(4/5) You can add custom instructions or style guidelines for the agent here!}

Context used:

• Context from dashboard - AGENTS.md (source)

[vercel]

@tanujbhaud is attempting to deploy a commit to the Amantus Machina Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

convex/auth.ts
Soft-delete bypass
If this change allows re-authentication without requiring existingUserId, it likely makes the "reactivate" path depend on whatever identifier is present in the fresh-login payload. That can accidentally merge/attach a login to the wrong soft-deleted account if the identifier isn’t stable/unique across providers or isn’t validated against the identity provider’s subject. Please ensure reactivation only happens when you can prove the incoming identity matches the soft-deleted user (e.g., provider+subject match) and otherwise create a new user.

Prompt To Fix With AI

This is a comment left during a code review.
Path: convex/auth.ts
Line: 1:3

Comment:
**Soft-delete bypass**
If this change allows re-authentication without requiring `existingUserId`, it likely makes the "reactivate" path depend on whatever identifier is present in the fresh-login payload. That can accidentally merge/attach a login to the wrong soft-deleted account if the identifier isn’t stable/unique across providers or isn’t validated against the identity provider’s subject. Please ensure reactivation only happens when you can prove the incoming identity matches the soft-deleted user (e.g., provider+subject match) and otherwise create a new user.


How can I resolve this? If you propose a fix, please make it concise.

[tanujbhaud]

Resolved: Added a check to ensure matches before reactivation, preventing potential soft-delete bypass.

[tanujbhaud]

Resolved: Added a check to ensure 'existingUserId' matches 'userId' before reactivation, preventing potential soft-delete bypass.

[tanujbhaud]

Fixed the logic error: now allowing re-authentication when existingUserId is null (fresh login) while still preventing mismatches if an existing ID is present.