fix(webapp): accept Plain customers without an external id on customer cards - #4575
fix(webapp): accept Plain customers without an external id on customer cards#4575isshaddad wants to merge 2 commits into
Conversation
…r cards
Plain sends customer.externalId as an explicit null rather than omitting the key,
and the schema validated it with z.string().optional(), which accepts undefined
but rejects null. Every customer we don't set an externalId for got a 400 instead
of a card, while the rest worked — so it looked intermittent.
email, externalId and thread are now nullish; one of email/externalId is still
required, and the existing email fallback resolves these customers.
Two related fixes in the same path:
- The route returned { cards: [] } when no user matched. Plain records an
integration error for any requested key it doesn't get back, so that rendered
as a broken card rather than a hidden one. Every requested key is now answered,
with components: null where there's no data.
- The impersonation link is offered only when the customer matched on externalId,
a value we set ourselves. An email match is a weaker claim — the address on a
Plain customer isn't verified and, for customers created outside our own
writes, comes from whoever sent the message — so email-matched customers now
get the account rows without a one-click impersonation link.
- The not-found log recorded raw customer identifiers; it keeps presence flags
only.
The schema and the response helper live in app/utils so they can be unit-tested
without pulling in the db and env modules.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent review details⏰ Context from checks skipped due to timeout. (6)
🧰 Additional context used📓 Path-based instructions (11)**/*.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
{packages/core,apps/webapp}/**/*.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.{ts,tsx,js,jsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.{test,spec}.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.ts📄 CodeRabbit inference engine (.cursor/rules/otel-metrics.mdc)
Files:
apps/webapp/**/*.{ts,tsx}📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Files:
apps/webapp/**/*.test.{ts,tsx}📄 CodeRabbit inference engine (.cursor/rules/webapp.mdc)
Files:
apps/**/*.{ts,tsx}📄 CodeRabbit inference engine (AGENTS.md)
Files:
apps/webapp/app/**/*.{ts,tsx}📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Files:
apps/webapp/app/**/*.ts📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Files:
apps/webapp/**/*.{test,spec}.{ts,tsx}📄 CodeRabbit inference engine (apps/webapp/CLAUDE.md)
Files:
🧠 Learnings (14)📚 Learning: 2026-03-22T13:26:12.060ZApplied to files:
📚 Learning: 2026-03-22T19:24:14.403ZApplied to files:
📚 Learning: 2026-05-18T08:21:27.694ZApplied to files:
📚 Learning: 2026-05-18T08:21:27.694ZApplied to files:
📚 Learning: 2026-06-13T19:53:13.759ZApplied to files:
📚 Learning: 2026-06-17T17:13:49.929ZApplied to files:
📚 Learning: 2026-06-23T13:04:21.413ZApplied to files:
📚 Learning: 2026-05-12T21:04:05.815ZApplied to files:
📚 Learning: 2026-06-25T18:21:51.905ZApplied to files:
📚 Learning: 2026-07-03T17:10:21.498ZApplied to files:
📚 Learning: 2026-05-18T14:40:02.173ZApplied to files:
📚 Learning: 2026-06-04T18:16:35.386ZApplied to files:
📚 Learning: 2026-06-09T17:58:04.699ZApplied to files:
📚 Learning: 2026-06-16T09:19:47.637ZApplied to files:
🔇 Additional comments (6)
WalkthroughThe change moves Plain customer card request validation into a shared Zod schema. It adds email normalization and a helper that fills missing requested card keys with empty cards. The route uses these utilities for user lookup and response completion. Logs no longer include customer identifiers. Impersonation controls and tokens are generated only for customers matched by 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| * loaded on the customer page rather than in a thread. `.optional()` accepts `undefined` but | ||
| * rejects `null`, which failed the whole request before any lookup could run. | ||
| */ | ||
| export const PlainCustomerCardRequestSchema = z.object({ |
There was a problem hiding this comment.
🟡 Server-only change ships without a release-notes entry
This pull request changes only webapp server code (apps/webapp/app/routes/api.v1.plain.customer-cards.ts, apps/webapp/app/utils/plainCustomerCards.ts) without adding the required release-notes file, so the fix will be missing from the user-visible release notes.
Impact: Users reading the release notes won't see that support cards now work for customers we don't set an id for.
Repository rule: server-only PRs must add a `.server-changes/` entry
AGENTS.md and CONTRIBUTING.md state that when modifying only server components (apps/webapp/, apps/supervisor/, etc.) with no package changes, a .server-changes/ markdown file must be added (frontmatter area: webapp, type: fix, plus a one-line user-facing description — see .server-changes/README.md:7-39). The PR touches only apps/webapp/** and adds no such file.
Prompt for agents
This PR only changes server code under apps/webapp, so per AGENTS.md / CONTRIBUTING.md / .server-changes/README.md it needs a new markdown file in .server-changes/ (e.g. .server-changes/fix-plain-customer-cards.md) with frontmatter `area: webapp` and `type: fix`, and a one-line, user-facing body describing that support customer cards now load for customers without an external id.
Was this helpful? React with 👍 or 👎 to provide feedback.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Users are stored with a lowercased, trimmed email and User.email is unique, so an exact lookup on whatever Plain sends missed a real account whenever the address arrived with different casing or padding — which it can, since for customers created outside our own writes it comes from a sender address. Reachable only now that a null externalId no longer 400s. The external id lookup also falls back to email when it doesn't resolve, so a stale id naming a deleted user no longer leaves the card blank for a customer we could still identify. canImpersonate is derived from which lookup matched rather than from whether an external id was sent, so falling through to email cannot unlock the impersonation link.
| // The external id is ours (`User.id`), so it's tried first. Falling back to email when it | ||
| // doesn't resolve covers a stale id — one naming a user row that no longer exists — instead of | ||
| // leaving the card blank for a customer we could still identify. | ||
| const byExternalId = customer.externalId | ||
| ? await prisma.user.findFirst({ where: { id: customer.externalId }, include: userInclude }) | ||
| : null; | ||
|
|
||
| const email = normalizeEmail(customer.email); | ||
| const user = | ||
| byExternalId ?? | ||
| (email ? await prisma.user.findFirst({ where: { email }, include: userInclude }) : null); |
There was a problem hiding this comment.
🔍 Stale externalId now silently falls back to an email match
Previously an externalId short-circuited the lookup entirely; now a non-matching externalId falls through to an email lookup (apps/webapp/app/routes/api.v1.plain.customer-cards.ts:123-130). That means a Plain customer whose external id points at a user that no longer exists (or a mistyped id) will render whichever account matches the sender address instead of an empty card. Impersonation is correctly gated off byExternalId, so no elevated action follows, but agents will see account rows attributed via an unverified email — worth confirming this is the desired support UX.
Was this helpful? React with 👍 or 👎 to provide feedback.
| .map( | ||
| (key): NoDataCard => ({ | ||
| key, | ||
| components: null, | ||
| }) | ||
| ), |
There was a problem hiding this comment.
🔍 No-data cards omit timeToLiveSeconds
The fill-in cards from answerAllCardKeys contain only { key, components: null } while the real cards specify timeToLiveSeconds (15/300). Depending on Plain's defaults, a missing TTL may mean the empty card is cached with a default lifetime, so a customer who becomes resolvable (e.g. after an externalId is set) may keep showing a hidden card until the default TTL elapses. Worth checking Plain's documented default TTL for card responses.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Plain sends
customer.externalIdas an explicitnullrather than omitting the key. The schema validated it withz.string().optional(), which acceptsundefinedbut rejectsnull, so every customer we don't set anexternalIdfor got a 400 instead of a card — while the rest worked, which made it look intermittent.email,externalIdandthreadare nownullish. One of email/externalId is still required, and the route's existing email fallback resolves these customers.Three related fixes in the same path:
{ cards: [] }when no user matched. Plain records an integration error for any requested key it doesn't get back, so that surfaced as a broken card rather than a hidden one. Every requested key is now answered, withcomponents: nullwhere there's no data.externalId— a value we set ourselves. An email match is a weaker claim, since the address on a Plain customer isn't verified and for customers created outside our own writes it comes from whoever sent the message. Email-matched customers get the account rows without a one-click impersonation link.The schema and the response helper moved to
app/utils/plainCustomerCards.tsso they can be unit-tested without pulling in the db and env modules.Testing
app/utils/plainCustomerCards.test.ts— 11 tests covering the null shapes, the every-key-answered response, and the missing-vs-zero distinction. Verified locally.Split out of #4571, which bundled this with an unrelated impersonation fix.