refactor(lane-4): pipelineAlert() helper for FE Sentry signals#1914
refactor(lane-4): pipelineAlert() helper for FE Sentry signals#1914Hugo0 wants to merge 2 commits intoqa/post-cutover-fe-fixesfrom
Conversation
Mirror the BE pipelineAlert helper. Migrates the transformer default-arm unknown-kind alert to the shared schema (component=pipeline, fixed category union, intentKind tag), so BE+FE pipeline events filter on the same dashboard query. Pairs with peanut-api-ts PR #679.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✅ Files skipped from review due to trivial changes (3)
WalkthroughAdds a new pipeline alerts utility that centralizes lazy Sentry message capture with category tagging and metadata. Replaces direct/lazy Sentry usage in the transaction transformer with Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
Review rate limit: 3/5 reviews remaining, refill in 22 minutes and 59 seconds. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/utils/pipelineAlerts.ts (1)
42-42: Avoid fully silent failure handling in the alert path.Swallowing all errors here makes helper regressions hard to detect locally. Consider logging only in development while keeping production no-op behavior.
Proposed fix
- .catch(() => {}) + .catch((err) => { + if (process.env.NODE_ENV === 'development') { + console.warn('pipelineAlert failed', err) + } + })🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/utils/pipelineAlerts.ts` at line 42, Replace the empty catch handler (.catch(() => {})) in src/utils/pipelineAlerts.ts with a handler that surfaces the error during development but remains a no-op in production; e.g. change to .catch(err => { if (process.env.NODE_ENV === 'development') console.error('pipelineAlerts error:', err); }) so failures in the alert path are logged locally while production behavior stays silent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/utils/pipelineAlerts.ts`:
- Around line 35-39: The tag value for intentKind is using a TypeScript cast
only and can still receive non-string runtime values; compute a runtime-checked
string before calling Sentry.captureMessage — e.g., derive intentKind = typeof
extra?.kind === 'string' ? extra.kind : 'n/a' (or use String(...) only after a
typeof check) and use that variable in the tags object (referencing the existing
extra variable and the tags key intentKind in the Sentry.captureMessage call) so
the tag is always a stable string.
---
Nitpick comments:
In `@src/utils/pipelineAlerts.ts`:
- Line 42: Replace the empty catch handler (.catch(() => {})) in
src/utils/pipelineAlerts.ts with a handler that surfaces the error during
development but remains a no-op in production; e.g. change to .catch(err => { if
(process.env.NODE_ENV === 'development') console.error('pipelineAlerts error:',
err); }) so failures in the alert path are logged locally while production
behavior stays silent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5810f289-1831-4a66-bd93-5540e3e8c33e
📒 Files selected for processing (2)
src/components/TransactionDetails/transactionTransformer.tssrc/utils/pipelineAlerts.ts
| .then((Sentry) => | ||
| Sentry.captureMessage(message, { | ||
| level, | ||
| tags: { component: 'pipeline', category, intentKind: (extra.kind as string | undefined) ?? 'n/a' }, | ||
| extra, |
There was a problem hiding this comment.
Harden intentKind extraction to guarantee stable tag values.
(extra.kind as string | undefined) is compile-time only; non-string runtime values can leak into tags and fragment the dashboard filter schema.
Proposed fix
export function pipelineAlert(
@@
): void {
if (typeof window === 'undefined') return
import('@sentry/nextjs')
- .then((Sentry) =>
- Sentry.captureMessage(message, {
+ .then((Sentry) => {
+ const intentKind =
+ typeof extra.kind === 'string' && extra.kind.trim().length > 0 ? extra.kind : 'n/a'
+ Sentry.captureMessage(message, {
level,
- tags: { component: 'pipeline', category, intentKind: (extra.kind as string | undefined) ?? 'n/a' },
+ tags: { component: 'pipeline', category, intentKind },
extra,
})
- )
+ })
.catch(() => {})
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/utils/pipelineAlerts.ts` around lines 35 - 39, The tag value for
intentKind is using a TypeScript cast only and can still receive non-string
runtime values; compute a runtime-checked string before calling
Sentry.captureMessage — e.g., derive intentKind = typeof extra?.kind ===
'string' ? extra.kind : 'n/a' (or use String(...) only after a typeof check) and
use that variable in the tags object (referencing the existing extra variable
and the tags key intentKind in the Sentry.captureMessage call) so the tag is
always a stable string.
Summary
Mirror the BE `pipelineAlert` helper. Migrate the transformer default-arm
unknown-kind alert to the shared schema (`component=pipeline`, fixed
category union, `intentKind` tag), so BE+FE pipeline events filter on the
same dashboard query.
Pairs with
peanutprotocol/peanut-api-ts#679
Verified
Base
Stacked on `qa/post-cutover-fe-fixes` (PR #1912).