Conversation
WalkthroughThis pull request introduces a centralized Sentry event filtering utility for filename exceptions and refactors existing filtering logic to use it. A new Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 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 |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
__tests__/utils/sentry-client-filters.test.ts (2)
7-16: Consider using proper type instead ofas any.The test correctly validates frame-based filtering, but the
as anytype assertion bypasses type safety. Consider importing and usingSentryStackFramefrom the utility module.Apply this diff to improve type safety:
+import { + __testing, + shouldFilterByFilenameExceptions, + SentryStackFrame, +} from "@/utils/sentry-client-filters"; it("filters events when a stack frame matches a filename exception", () => { // Arrange - const frames = [{ filename: "app:///extensionServiceWorker.js" } as any]; + const frames: SentryStackFrame[] = [{ filename: "app:///extensionServiceWorker.js" }]; // Act const result = shouldFilterByFilenameExceptions(frames); // Assert expect(result).toBe(true); });
32-41: Consider using proper type instead ofas any.Same as the earlier test, consider using
SentryStackFrametype instead ofas anyfor better type safety.Apply this diff:
it("does not filter when frames do not match any filename exception", () => { // Arrange - const frames = [{ filename: "app:///main.js" } as any]; + const frames: SentryStackFrame[] = [{ filename: "app:///main.js" }]; // Act const result = shouldFilterByFilenameExceptions(frames); // Assert expect(result).toBe(false); });
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
__tests__/utils/sentry-client-filters.test.ts(1 hunks)codex/STATE.md(1 hunks)codex/tickets/TKT-0037.md(1 hunks)instrumentation-client.ts(2 hunks)utils/sentry-client-filters.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (11)
codex/**/*.{md,yml,yaml}
📄 CodeRabbit inference engine (AGENTS.md)
Review
codex/STATE.mdat the start of every workstream; keep tickets in sync withcodex/tickets/; author new tickets with provided template, keep alphabetical YAML front matter, and log timestamped updates
Files:
codex/tickets/TKT-0037.mdcodex/STATE.md
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursorrules)
**/*.{ts,tsx,js,jsx}: Do not include any comments in the code; it should be self-explanatory
Write correct, up-to-date, bug-free, fully componentized, secure, and efficient code
Include all required imports and ensure proper naming of key components
Use NextJS features that match the current version
**/*.{ts,tsx,js,jsx}: Replace<img>elements with<Image />fromnext/imageto satisfy@next/next/no-img-elementESLint rule
Use<Link href="/path">from Next.js for internal navigation instead of plain HTML links to satisfy@next/next/no-html-link-for-pagesESLint rule
Files:
__tests__/utils/sentry-client-filters.test.tsinstrumentation-client.tsutils/sentry-client-filters.ts
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{js,jsx,ts,tsx}: Code must satisfy ESLint (Next's Core Web Vitals + React Hooks)
Use framework APIs: internal links should use<Link>, images should usenext/image, and adopt Next's ESLint rules (Core Web Vitals)
**/*.{js,jsx,ts,tsx}: Code must satisfy ESLint (Next's Core Web Vitals + React Hooks rules)
Follow existing code style and naming conventions; maintain clean code standards (measured by SonarQube)
Files:
__tests__/utils/sentry-client-filters.test.tsinstrumentation-client.tsutils/sentry-client-filters.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{ts,tsx}: Must passtsc --noEmittype checking
Prefer direct named imports for React hooks and types (import { useMemo, useRef, FC, etc. } from "react") overReact.namespace usage (React.useMemo,React.useRef, etc.)
If thereact-hooks/exhaustive-depslint rule is triggered: if the Effect only derives state, remove the Effect and compute during render; if listening to an external system and needing fresh props/state, wrap non-reactive logic inuseEffectEvent
**/*.{ts,tsx}: Must passtsc --noEmitfor TypeScript type checking
Prefer Server Components over Client Components; use Server Functions/Server Actions ('use server') for mutations
Remove unnecessary Effects; if Effect only derives state, compute during render instead
UseuseEffectEventfor non-reactive logic inside Effects to avoid unnecessary re-runs
Use framework APIs:<Link>for internal links,next/imagefor images, adopt Next's ESLint rules
Use'use cache'directive and Cache Components features for explicit opt-in caching in Next.js 16
Use TypeScript and React functional components with hooks
When parsing Seize URLs or similar, fail fast if base origin is unavailable; do not fall back to placeholder origins
Replace<img>elements with<Image />fromnext/image
Use<Link href="/path">for internal navigation instead of plain HTML links
Move data fetches to Server Components; handle mutations through Server Functions/Server Actions with'use server'directive
Files:
__tests__/utils/sentry-client-filters.test.tsinstrumentation-client.tsutils/sentry-client-filters.ts
**/@(__tests__|*.test).{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Tests should live in
__tests__/orComponentName.test.tsx; mock external dependencies and APIs in tests
Files:
__tests__/utils/sentry-client-filters.test.ts
**/__tests__/**/*.{ts,tsx}
📄 CodeRabbit inference engine (GEMINI.md)
Place tests in
__tests__/directory or asComponentName.test.tsxalongside components
Files:
__tests__/utils/sentry-client-filters.test.ts
**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (GEMINI.md)
Mock external dependencies and APIs in tests
Files:
__tests__/utils/sentry-client-filters.test.ts
__tests__/**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (tests/AGENTS.md)
Use Jest +
ts-jestfor TypeScript testing
Files:
__tests__/utils/sentry-client-filters.test.ts
__tests__/**/*.{ts,tsx}
📄 CodeRabbit inference engine (tests/AGENTS.md)
Functions must have ≤ 15 cognitive complexity; extract deep ternaries (>3 levels) and break down complex logic
Files:
__tests__/utils/sentry-client-filters.test.ts
__tests__/**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (tests/AGENTS.md)
__tests__/**/*.{ts,tsx,js}: Preferfor...ofloops overforEachas it allowsbreak/continueand works with async/await
Usearray.at(-1)andarray.at(-2)instead of index-based array access for negative indexing
UseString.prototype.replaceAll()instead ofreplace()for global string replacements
UseglobalThis.fetch()instead of directfetch()calls
Organize imports with one import per module in order: external → internal → types, with no duplicates
Useelement.remove()instead ofparent.removeChild(element)for DOM manipulation
Catch errors only when meaningful; no empty catch blocks; log errors with context
Avoid double negatives in code; prefer explicit logic and remove redundant annotations; use optional chaining (?.)
Files:
__tests__/utils/sentry-client-filters.test.ts
@(instrumentation-client.ts|sentry.server.config.ts|sentry.edge.config.ts)
📄 CodeRabbit inference engine (AGENTS.md)
Errors should be filtered in the Sentry
beforeSendcallback; client-side filtering happens ininstrumentation-client.ts, server-side insentry.server.config.ts, and edge runtime insentry.edge.config.ts
Files:
instrumentation-client.ts
🧠 Learnings (13)
📓 Common learnings
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-03T14:52:34.271Z
Learning: Applies to @(instrumentation-client.ts|sentry.server.config.ts|sentry.edge.config.ts) : Errors should be filtered in the Sentry `beforeSend` callback; client-side filtering happens in `instrumentation-client.ts`, server-side in `sentry.server.config.ts`, and edge runtime in `sentry.edge.config.ts`
📚 Learning: 2025-12-03T14:52:34.271Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-03T14:52:34.271Z
Learning: Applies to @(instrumentation-client.ts|sentry.server.config.ts|sentry.edge.config.ts) : Errors should be filtered in the Sentry `beforeSend` callback; client-side filtering happens in `instrumentation-client.ts`, server-side in `sentry.server.config.ts`, and edge runtime in `sentry.edge.config.ts`
Applied to files:
codex/tickets/TKT-0037.md__tests__/utils/sentry-client-filters.test.tsinstrumentation-client.tsutils/sentry-client-filters.ts
📚 Learning: 2025-12-05T10:55:43.476Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: __tests__/AGENTS.md:0-0
Timestamp: 2025-12-05T10:55:43.476Z
Learning: Applies to __tests__/**/*.{ts,tsx,js} : Avoid double negatives in code; prefer explicit logic and remove redundant annotations; use optional chaining (`?.`)
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-03T14:52:34.271Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-03T14:52:34.271Z
Learning: Applies to **/@(__tests__|*.test).{ts,tsx} : Tests should live in `__tests__/` or `ComponentName.test.tsx`; mock external dependencies and APIs in tests
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-05T10:55:43.476Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: __tests__/AGENTS.md:0-0
Timestamp: 2025-12-05T10:55:43.476Z
Learning: Applies to __tests__/**/__tests__/**/*.test.{ts,tsx,js} : Test high-risk areas including happy path workflows, invalid input errors, edge cases/boundaries, component & API interactions, and performance/security when relevant
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-05T10:55:43.476Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: __tests__/AGENTS.md:0-0
Timestamp: 2025-12-05T10:55:43.476Z
Learning: Applies to __tests__/**/__tests__/**/*.test.{ts,tsx,js} : Keep tests independent, deterministic, and fast with production-like data
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-05T10:55:43.476Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: __tests__/AGENTS.md:0-0
Timestamp: 2025-12-05T10:55:43.476Z
Learning: Applies to __tests__/**/*.{ts,tsx,js} : Catch errors only when meaningful; no empty catch blocks; log errors with context
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-05T10:55:43.476Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: __tests__/AGENTS.md:0-0
Timestamp: 2025-12-05T10:55:43.476Z
Learning: Applies to __tests__/**/__tests__/**/*.test.{ts,tsx,js} : All tests must live in `__tests__`, mirroring source folders (`components`, `contexts`, `hooks`, `utils`)
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-05T10:55:30.871Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: GEMINI.md:0-0
Timestamp: 2025-12-05T10:55:30.871Z
Learning: Applies to **/__tests__/**/*.{ts,tsx} : Place tests in `__tests__/` directory or as `ComponentName.test.tsx` alongside components
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-05T10:55:43.476Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: __tests__/AGENTS.md:0-0
Timestamp: 2025-12-05T10:55:43.476Z
Learning: Applies to __tests__/**/__tests__/**/*.test.{ts,tsx,js} : Write tests following Arrange – Act – Assert pattern with one behaviour per test and clear, descriptive names
Applied to files:
__tests__/utils/sentry-client-filters.test.ts
📚 Learning: 2025-12-03T14:52:34.271Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-12-03T14:52:34.271Z
Learning: Applies to codex/**/*.{md,yml,yaml} : Review `codex/STATE.md` at the start of every workstream; keep tickets in sync with `codex/tickets/`; author new tickets with provided template, keep alphabetical YAML front matter, and log timestamped updates
Applied to files:
codex/STATE.md
📚 Learning: 2025-11-25T08:36:33.029Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: .cursor/rules/self_improve.mdc:0-0
Timestamp: 2025-11-25T08:36:33.029Z
Learning: Monitor code review comments, track common development questions, update rules after major refactors, add links to relevant documentation, and cross-reference related rules for continuous improvement
Applied to files:
codex/STATE.md
📚 Learning: 2025-11-25T08:36:24.149Z
Learnt from: CR
Repo: 6529-Collections/6529seize-frontend PR: 0
File: .cursor/rules/dev_workflow.mdc:0-0
Timestamp: 2025-11-25T08:36:24.149Z
Learning: Applies to .cursor/rules/**/*.mdc : After subtask implementation is complete, review code changes and chat history to identify new code patterns and conventions, then create or update Cursor rules in `.cursor/rules/` directory to capture these patterns following cursor_rules.mdc and self_improve.mdc guidelines
Applied to files:
codex/STATE.md
🧬 Code graph analysis (2)
__tests__/utils/sentry-client-filters.test.ts (1)
utils/sentry-client-filters.ts (2)
shouldFilterByFilenameExceptions(35-40)__testing(42-42)
instrumentation-client.ts (1)
utils/sentry-client-filters.ts (1)
shouldFilterByFilenameExceptions(35-40)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (13)
codex/STATE.md (1)
43-43: LGTM!The new ticket entry is properly formatted, follows alphabetical ordering, and includes all required metadata fields.
__tests__/utils/sentry-client-filters.test.ts (3)
18-30: LGTM!This test effectively validates stack-based filtering by constructing a realistic error with a stack trace containing the target filename pattern.
43-55: LGTM!This test provides good coverage of the negative case where the exception stack does not contain any filtered filenames.
57-66: LGTM!This test validates that the specific filename pattern from TKT-0037 is included in the filter list, directly addressing the ticket's requirements.
utils/sentry-client-filters.ts (4)
1-5: LGTM!The type definitions are minimal, focused, and align with Sentry SDK structures. They provide sufficient type safety for the filtering logic.
7-7: LGTM!The filename exceptions list appropriately targets common browser extension patterns that generate noise in Sentry, including the specific
extensionServiceWorker.jsmentioned in TKT-0037.
9-33: LGTM!Both helper functions use defensive programming with appropriate early returns and handle edge cases properly. The dual check of
filenameandabs_pathin frames provides good coverage, and the string-based stack matching is appropriate for stack trace analysis.
35-42: LGTM!The public API appropriately combines both filtering strategies with OR logic, and the
__testingexport follows best practices for exposing internal state to tests without polluting the public API.instrumentation-client.ts (2)
10-10: LGTM!The import correctly uses a direct named import with the project's path alias convention.
68-69: LGTM!The refactored code correctly delegates to the centralized utility, passing both the extracted frames and the hint. This aligns with the established pattern of filtering errors in the Sentry
beforeSendcallback. Based on learnings, client-side filtering happens in instrumentation-client.ts.codex/tickets/TKT-0037.md (3)
1-8: LGTM!The YAML front matter follows the required template with alphabetically ordered fields, proper date format, and valid metadata values. As per coding guidelines, codex tickets should maintain alphabetical YAML front matter.
32-34: LGTM!The log entry follows the required format with an ISO 8601 timestamp and accurately describes the changes implemented in this PR. As per coding guidelines, tickets should log timestamped updates.
14-19: Ticket follows template and documents plan correctly.The unchecked items on lines 18–19 are implementation milestones, not prerequisites for this ticket file. The Plan shows completed work (lines 16–17 ✓); the remaining items represent pre-merge verification (run tests) and post-merge validation (production Sentry check). No action needed on the ticket file itself.
Likely an incorrect or invalid review comment.
2 participants
Summary by CodeRabbit
Tests
Improvements
✏️ Tip: You can customize this high-level summary in your review settings.