Skip to content

chore: bump @friggframework/* deps to 2.0.0-next.83#97

Merged
d-klotz merged 1 commit into
mainfrom
chore/bump-frigg-next-83
May 5, 2026
Merged

chore: bump @friggframework/* deps to 2.0.0-next.83#97
d-klotz merged 1 commit into
mainfrom
chore/bump-frigg-next-83

Conversation

@d-klotz
Copy link
Copy Markdown
Contributor

@d-klotz d-klotz commented May 5, 2026

Summary

Bump @friggframework/* deps from 2.0.0-next.822.0.0-next.83. Pulls in Frigg PR #583 — follow-up to next.82's #582.

Why

Validating next.82 in dev surfaced a second bug: when a user re-authenticates against a different workspace/account of the same provider (the user has multiple Pipedrive workspaces and authenticates against them interchangeably), upsertCredential matches a different credential row than the entity was previously linked to.

Concrete sequence observed in dev (Pipedrive integration 136, user 16):

  • Entity 159 was previously linked to credential 166 (workspace 23384438).
  • Today's re-auth went through Pipedrive workspace 24952048 → matched existing credential 188 (a separate cred for that workspace).
  • The OAuth callback returned {credentialId: 188, entityId: 159}, but the DB-level FK on entity 159 still pointed to credential 166.
  • The integration kept running against credential 166's stale tokens; webhook setup only succeeded because credential 166's separate refresh_token happened to still be alive (the runtime's auto-refresh kicked in and silently rotated cred 166).

In other words, the "fix" in next.82 wrote the new tokens to the right credential row, but the entity wasn't repointed to use them.

What's in next.83

  • findOrCreateEntity now repoints existingEntity.credentialId to the just-upserted credentialId via moduleRepository.updateEntity whenever they differ.
  • No-ops when they match (no extra DB write on the common path).
  • Logs [Frigg] Repointing entity X credentialId Y -> Z after re-auth whenever it fires — surfaces this scenario in CloudWatch.

Test plan

  • npm install resolves cleanly with the new versions
  • Deploy to dev; re-install Pipedrive against a different workspace than the existing entity's; confirm the new Repointing entity ... log line appears AND that the entity's credentialId foreign key in the DB updates to point at the freshly-persisted credential
  • Re-install against the SAME workspace; confirm no Repointing log line (no-op path)

🤖 Generated with Claude Code

Pulls in Frigg PR #583 (fix(core): repoint entity credentialId when
re-auth produces a different credential) — follow-up to #582.

Found via dev validation: re-auth against a different Pipedrive
workspace left the entity pointing at the prior credential row while
the freshly-issued tokens landed on a different credential. fix
repoints existing entity's credentialId to the just-upserted credential
when they differ.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@d-klotz d-klotz merged commit 139f51a into main May 5, 2026
3 checks passed
@d-klotz d-klotz deleted the chore/bump-frigg-next-83 branch May 5, 2026 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant