Conversation
…tegration and external user ID support (#2298) - Added externalUserId and externalUserSource fields to Member model and database schema. - Updated SyncController to utilize new RampUser and RampUserStatus types. - Implemented retry logic for fetching Ramp users to handle API rate limits and errors. - Introduced employeeSyncCheck for auditing and syncing users from Ramp. - Filtered out non-syncable user statuses during synchronization process. Co-authored-by: Tofik Hasanov <annexcies@gmail.com> Co-authored-by: Tofik Hasanov <72318342+tofikwest@users.noreply.github.com>
PR SummaryMedium Risk Overview Hardens Ramp user fetching with retries/backoff for Adds a new Ramp integration check ( Written by Cursor Bugbot for commit 8c84f19. This will update automatically on new commits. Configure here. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| `Skipping ${skippedStatuses.length} Ramp users with non-syncable statuses (INVITE_PENDING, INVITE_EXPIRED, USER_ONBOARDING)`, | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
Non-syncable users logged but never filtered out
High Severity
The code at lines 1173–1186 identifies Ramp users with non-syncable statuses (INVITE_PENDING, INVITE_EXPIRED, USER_ONBOARDING) and logs "Skipping" them, but never actually filters the users array. The unfiltered users feeds into rampDomains (line 1354), so non-syncable users' emails end up in no email set (activeEmails, inactiveEmails, suspendedEmails), causing isRemoved to be true for matching org members — incorrectly deactivating them. The companion employee-sync.ts check correctly filters with allUsers.filter(...) into a new syncableUsers array.
Additional Locations (2)
…d session cookies for authentication (#2300) Co-authored-by: Tofik Hasanov <annexcies@gmail.com>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 2 total unresolved issues (including 1 from previous review).
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| ) { | ||
| continue; | ||
| } | ||
|
|
There was a problem hiding this comment.
Deactivation undoes external-ID-based email change handling
High Severity
The import phase matches members by externalUserId to "handle email changes" (per the comment), but the deactivation phase only matches by email. If a Ramp user changed their email, the import phase correctly finds the member via external ID and skips it as "Already a member" — without updating the user's email on the user record. Then the deactivation loop checks the member's old email against activeEmails, doesn't find it, and deactivates the member as USER_MISSING. This undoes the external ID matching from moments earlier, making the email-change handling counterproductive — a regression from the pre-PR behavior where at least a new member with the new email would have been created.
Additional Locations (1)
|
🎉 This PR is included in version 3.5.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
2 participants
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.