fix(core): repoint entity credentialId when re-auth produces a different credential#583
Merged
Merged
Conversation
…ent credential
When a user re-authenticates against a different workspace/account of the
same provider (e.g. switching between two Pipedrive workspaces),
upsertCredential matches/creates a credential keyed by externalId from
getCredentialDetails — but findEntity matches the entity by its own
externalId from getEntityDetails. These keys can resolve to different
credential rows when the user has multiple workspaces, leaving the
entity still linked to the prior workspace's credential after re-auth.
Without this fix, the OAuth callback reports
{credentialId, entityId} where credentialId is the freshly-persisted
credential, but the entity in the DB still references a different
credential. Downstream integration creation reads the stale link and
runs against the prior workspace's tokens, while the just-issued tokens
sit on a different credential row no entity points to.
Repoint the entity's credentialId via moduleRepository.updateEntity
when findOrCreateEntity returns an existing entity whose credentialId
differs from the just-upserted credential.
Tests: two new cases — repoints when upsert produces a different
credential, no-ops when the entity already points at the upserted one.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
🚀 PR was released in |
3 tasks
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #582. When a user re-authenticates against a different workspace/account of the same provider (e.g. switching between two Pipedrive workspaces under the same Frigg user), the re-auth flow leaves the entity linked to the prior workspace's credential while the freshly-issued tokens land on a different credential row.
Root cause
upsertCredentialmatches/creates a credential keyed by externalId fromgetCredentialDetails(e.g. PipedriveuserProfile.data.id).findOrCreateEntitymatches the entity by its own externalId fromgetEntityDetails(e.g. PipedriveuserProfile.data.company_id). When the user has multiple workspaces, both methods can hit different existing rows —upsertCredentialresolves to credential B's row,findOrCreateEntityreturns the entity already pointing at credential A.The OAuth callback then reports
{ credentialId: B, entityId: matched-entity }, but the entity'scredentialIdforeign key still references A. Downstream integration creation reads the stale link, and the just-issued tokens sit on credential B with no entity pointing to it.Observed in dev
24952048(cred 188).23384438from a prior install).Fix
findOrCreateEntitynow repointsexistingEntity.credentialIdto the just-upsertedcredentialIdviamoduleRepository.updateEntitywhenever they differ. No-ops when they match.Tests
repoints existing entity credentialId when re-auth produces a different credential— locks in the new behaviordoes not repoint when the existing entity already points at the upserted credential— guards against unnecessary writes🤖 Generated with Claude Code