fix(website): suppress Sentry hydration and pushState noise (#434 #437) by ajitpratap0 · Pull Request #461 · ajitpratap0/GoSQLX

ajitpratap0 · 2026-03-29T09:21:37Z

Summary

Adds ignoreErrors array to Sentry client config to filter React hydration errors (feat(dialect): add ClickHouse SQL dialect support #418, fix(wasm): commit gosqlx.wasm to git — fixes production playground 404 #423, feat(website): Phase 1 marketing — star button, social share, playground CTA, WCAG, RSS #425) and browser extension noise
Expands beforeSend pushState filter from exact string match to case-insensitive toLowerCase().includes("pushstate") covering all TypeError variants
Adds belt-and-suspenders beforeSend hydration check for events that bypass ignoreErrors (e.g. unhandledrejection with no exception value)
Verified server-side instrumentation.ts config (no changes needed — hydration errors are client-side only)
Confirmed suppressHydrationWarning already present on <html> in layout.tsx

Fixes

Closes #434
Closes #437

Test plan

Deploy preview and verify Sentry dashboard shows reduced noise
Confirm legitimate errors still reach Sentry (test with a real error)
Verify no TypeScript errors (build passes cleanly)

🤖 Generated with Claude Code

Full-project audit using 5 parallel analytical personas (Performance, SQL Compatibility, API/DX, Competitive, Community). Synthesizes into prioritized P0–P3 roadmap covering: HN launch, query fingerprinting, linter expansion to 30 rules, DML transforms, C binding hardening, live DB schema introspection, SQL transpilation, CONNECT BY, OTel, GORM integration, and advisor expansion. Corresponding GitHub issues: #442–#460 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

12 implementation plans covering all prioritized GitHub issues: P0 (Critical): - 2026-03-29-sentry-fixes.md (#434, #437) — fix Sentry noise filters - 2026-03-29-openssf-scorecard.md (#443) — security scorecard badge P1 (High Priority): - 2026-03-29-query-fingerprinting.md (#444) — SQL normalization + SHA-256 fingerprints - 2026-03-29-linter-expansion.md (#445) — L011-L030 safety/performance/naming rules - 2026-03-29-dml-transforms.md (#446) — SET clause and RETURNING transforms - 2026-03-29-cbinding-hardening.md (#447) — C binding coverage + stress tests - 2026-03-29-advisor-expansion.md (#453) — OPT-009 through OPT-020 advisor rules P2 (Medium Priority): - 2026-03-29-sql-parser-additions.md (#450, #454, #455, #456) — DDL formatter, CONNECT BY, SAMPLE, PIVOT/UNPIVOT - 2026-03-29-schema-introspection.md (#448) — live DB schema introspection (Postgres, MySQL, SQLite) - 2026-03-29-integrations.md (#451, #452) — OpenTelemetry + GORM sub-modules - 2026-03-29-sql-transpilation.md (#449) — SQL dialect transpilation API P3 (Low Priority): - 2026-03-29-p3-items.md (#458, #459, #460) — CLI watch registration, pool stats, JSON functions Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…ushState noise - Add ignoreErrors array covering React hydration errors (#418, #423, #425), pushState read-only variants, and Chrome DevTools Protocol messages - Broaden beforeSend pushState filter from exact string to case-insensitive toLowerCase().includes("pushstate") to catch all TypeError variants (#434) - Add belt-and-suspenders beforeSend hydration check for events that bypass ignoreErrors (e.g. unhandledrejection without exception value) (#437) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

vercel · 2026-03-29T09:21:41Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gosqlx-website	Ready	Preview, Comment	Mar 29, 2026 0:21am

github-actions · 2026-03-29T09:21:49Z

Claude finished @ajitpratap0's task —— View job

PR Review: Sentry Noise Filtering

Todo List:

Review main Sentry configuration changes in instrumentation-client.ts
Analyze error filtering patterns and logic
Check for security and performance implications
Evaluate code quality and best practices
Provide comprehensive feedback and recommendations

🔍 Review Summary

This PR implements a comprehensive approach to filtering Sentry error noise, addressing React hydration errors and browser extension interference. The implementation is well-structured with both ignoreErrors and beforeSend filtering for defense in depth.

✅ Strengths

1. Defense in Depth Approach

Dual filtering strategy: Using both ignoreErrors and beforeSend ensures comprehensive coverage
Belt-and-suspenders logic: Catches events that might bypass the initial ignoreErrors filter
Clear separation: Different filtering mechanisms for different error types

2. Well-Documented Error Patterns

Excellent comments: Each error pattern includes context about why it occurs and why it should be filtered
Issue references: Links to specific GitHub issues ([Sentry] TypeError: Cannot assign to read only property 'pushState' of object '#<History>' #434, [Sentry] Hydration Error (replay) #437) for future maintainers
Clear categorization: Browser extensions vs. React hydration vs. DevTools Protocol

3. Performance Considerations

Early filtering: ignoreErrors prevents events from entering the pipeline entirely
Efficient string operations: Uses includes() for substring matching rather than complex regex where appropriate
Development debugging: Logs suppressed errors in development mode for visibility

⚠️ Areas for Improvement

1. Code Quality Issues

Redundant Filtering Logic (website/src/instrumentation-client.ts:49-58)

// This duplicates the ignoreErrors patterns
const isExtensionNoise =
  msg.toLowerCase().includes("pushstate") ||
  msg.includes("Object Not Found Matching Id:");

const isHydrationNoise =
  msg.includes("Text content does not match") ||
  msg.includes("Hydration failed") ||
  // ... more duplicated patterns

Recommendation: Extract error patterns into constants to avoid duplication:

const ERROR_PATTERNS = {
  PUSHSTATE_READONLY: /Cannot assign to read only property ['"]?pushState['"]?/i,
  HYDRATION_MISMATCH: "Text content does not match server-rendered HTML",
  // ... other patterns
} as const;

2. Regex vs String Matching Inconsistency

Mixed Approaches (website/src/instrumentation-client.ts:21 vs 49)

// In ignoreErrors: sophisticated regex
/Cannot assign to read only property ['"]?pushState['"]?/i,

// In beforeSend: simple string check
msg.toLowerCase().includes("pushstate")

Recommendation: The beforeSend approach is too broad - pushstate could match legitimate errors. Consider using the same regex pattern or a more specific substring.

3. Magic Numbers and Hardcoded Patterns

React Error Codes (website/src/instrumentation-client.ts:26-28)

"Minified React error #418",
"Minified React error #423", 
"Minified React error #425",

Recommendation: Add comments explaining what these specific React errors represent, or use constants with descriptive names.

4. Potential False Positives

Overly Broad Matching (website/src/instrumentation-client.ts:49)

msg.toLowerCase().includes("pushstate")

This could suppress legitimate errors that happen to mention "pushstate" in their message.

🛡️ Security Assessment

✅ No Security Concerns Identified

Error filtering only affects telemetry, not application behavior
No sensitive data exposure through error messages
Proper environment-based debug logging (development only)

🚀 Performance Impact

✅ Positive Performance Impact

Reduces unnecessary Sentry event transmission
Early filtering prevents processing overhead
String operations are efficient for the expected volume

📋 Test Coverage Recommendations

The PR mentions test plan items but they're not yet completed:

Missing Test Coverage:

Unit tests for the filtering logic in beforeSend
Integration tests to verify Sentry configuration loads correctly
E2E tests to confirm filtered errors don't appear in Sentry dashboard

Suggested Test Structure:

// Example test for filtering logic
describe('Sentry Error Filtering', () => {
  it('should suppress React hydration errors', () => {
    const mockEvent = {
      exception: {
        values: [{ value: 'Text content does not match server-rendered HTML' }]
      }
    };
    expect(beforeSendFilter(mockEvent)).toBeNull();
  });
});

🎯 Final Recommendations

High Priority

Consolidate error patterns into reusable constants
Make pushState filtering more specific to avoid false positives
Add unit tests for the filtering logic

Medium Priority

Document React error codes with explanations
Consider environment-specific filtering (stricter in production)
Add metrics to track how many errors are being filtered

Low Priority

Consider using TypeScript interfaces for better type safety
Add JSDoc comments for the filtering functions

✅ Overall Assessment

This is a well-implemented solution that addresses real noise issues in Sentry monitoring. The approach is sound, documentation is excellent, and the implementation shows good understanding of both Sentry and the specific error patterns being addressed.

Recommendation: Approve with minor changes - Address the code duplication and pushState filtering specificity before merging.

Job Run

github-actions · 2026-03-29T09:57:58Z

Claude encountered an error —— View job

I'll analyze this and get back to you.

Extract PUSHSTATE_REGEX as a shared constant used by both ignoreErrors and beforeSend, eliminating duplication. Replace overly broad msg.toLowerCase().includes("pushstate") with PUSHSTATE_REGEX.test(msg) to avoid suppressing legitimate errors that happen to mention pushState. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

github-actions · 2026-03-29T11:44:30Z

Claude finished @ajitpratap0's task —— View job

PR Review: Sentry Noise Filtering

Todo List:

Read and analyze main Sentry configuration changes in instrumentation-client.ts
Review error filtering patterns and logic implementation
Assess code quality, security, and performance implications
Identify potential bugs or edge cases
Evaluate test coverage needs and recommendations
Provide comprehensive feedback and recommendations

🔍 Review Summary

This PR implements a comprehensive approach to filtering Sentry error noise, addressing React hydration errors and browser extension interference. The implementation uses a defense-in-depth strategy with both ignoreErrors and beforeSend filtering.

✅ Strengths

1. Well-Architected Defense Strategy

The dual-layer approach is excellent:

ignoreErrors array (instrumentation-client.ts:22-34): Prevents noisy errors from entering Sentry pipeline entirely
beforeSend function (instrumentation-client.ts:35-71): Belt-and-suspenders filtering for edge cases that bypass ignoreErrors

2. Excellent Documentation & Context

Clear comments explaining each error pattern and why it should be filtered
Issue references ([Sentry] TypeError: Cannot assign to read only property 'pushState' of object '#<History>' #434, [Sentry] Hydration Error (replay) #437) linking to specific GitHub issues
Root cause explanations for browser extension conflicts and hydration mismatches

3. Performance Optimizations

Shared regex constant (instrumentation-client.ts:7): PUSHSTATE_REGEX prevents regex recompilation
Early filtering: ignoreErrors prevents unnecessary event processing
Development debugging (instrumentation-client.ts:64-66): Logs suppressed errors for visibility

⚠️ Issues & Recommendations

1. Code Duplication Between Filtering Layers

Problem: Error patterns are duplicated between ignoreErrors and beforeSend:

// In ignoreErrors (line 26):
"Text content does not match server-rendered HTML",

// In beforeSend (line 56):  
msg.includes("Text content does not match")

Impact: Maintenance burden, potential inconsistencies

Recommendation: Extract shared patterns to constants:

const ERROR_PATTERNS = {
  HYDRATION_MISMATCH: "Text content does not match server-rendered HTML",
  HYDRATION_FAILED: "Hydration failed because the server rendered HTML didn't match the client",
  // ...
} as const;

2. Inconsistent Pattern Matching Strategies

Problem: Mixed approaches between the two filtering layers:

ignoreErrors uses exact strings and precise regex
beforeSend uses loose includes() matching

Example (instrumentation-client.ts:56):

msg.includes("Text content does not match")  // Too broad

This could match legitimate errors containing that substring.

Recommendation: Use consistent, precise matching in both layers.

3. Undocumented React Error Codes

Problem: Magic numbers without context (instrumentation-client.ts:29-31):

"Minified React error #418",
"Minified React error #423", 
"Minified React error #425",

Recommendation: Add comments explaining what these specific error codes represent, or use descriptive constants.

4. Potential False Positive Risk

Problem: The Object Not Found Matching Id: regex (instrumentation-client.ts:33) uses a broad pattern that could match legitimate application errors.

Current: /Object Not Found Matching Id:\d+/

Recommendation: Consider more specific context or move to beforeSend only with additional validation.

🛡️ Security Assessment

✅ No Security Concerns

Error filtering only affects telemetry, not application behavior
No sensitive data exposure through error messages
Proper environment-based debug logging (development only)

🚀 Performance Impact

✅ Positive Impact

Reduces unnecessary Sentry event transmission and processing overhead
Early filtering with ignoreErrors is more efficient than beforeSend
String operations are lightweight for expected error volumes

📋 Test Coverage Recommendations

Missing Test Areas:

Unit tests for beforeSend filtering logic
Integration tests verifying Sentry configuration loads correctly
Mocking tests to ensure filtered errors don't reach Sentry

Suggested Test Structure:

// website/src/__tests__/sentry-filtering.test.ts
describe('Sentry Error Filtering', () => {
  it('should suppress React hydration errors', () => {
    const mockEvent = {
      exception: { values: [{ value: 'Text content does not match server-rendered HTML' }] }
    };
    expect(beforeSendFunction(mockEvent)).toBeNull();
  });

  it('should suppress pushState readonly errors', () => {
    const mockEvent = {
      exception: { values: [{ value: 'Cannot assign to read only property "pushState"' }] }
    };
    expect(beforeSendFunction(mockEvent)).toBeNull();
  });
});

🎯 Recommendations Summary

High Priority

Eliminate code duplication by extracting error patterns to shared constants
Standardize pattern matching approach across both filtering layers
Add unit tests for the filtering logic

Medium Priority

Document React error codes with explanations of what they represent
Review regex patterns for potential false positives
Consider environment-specific filtering (stricter patterns in production)

Low Priority

Add TypeScript interfaces for better type safety
Consider adding metrics to track filtering effectiveness

✅ Overall Assessment

This is a well-implemented solution that effectively addresses real Sentry noise issues. The approach demonstrates solid understanding of both Sentry filtering mechanisms and the specific error patterns being targeted.

Recommendation: ✅ Approve with minor improvements - The core implementation is sound, but addressing the code duplication and pattern consistency would strengthen maintainability.

The changes will significantly improve the signal-to-noise ratio in your Sentry monitoring without suppressing legitimate application errors.

github-actions · 2026-03-29T12:21:15Z

Claude finished @ajitpratap0's task —— View job

PR Review: Sentry Noise Filtering

Todo List:

Read and analyze main Sentry configuration changes in instrumentation-client.ts
Review error filtering patterns and logic implementation
Assess code quality, security, and performance implications
Identify potential bugs or edge cases
Evaluate test coverage needs and recommendations
Provide comprehensive feedback and recommendations

🔍 Review Summary

This PR implements a comprehensive approach to filtering Sentry error noise, addressing React hydration errors and browser extension interference. The implementation uses a defense-in-depth strategy with both ignoreErrors and beforeSend filtering.

✅ Strengths

1. Well-Architected Defense Strategy

The dual-layer approach is excellent:

ignoreErrors array (instrumentation-client.ts:22-34): Prevents noisy errors from entering Sentry pipeline entirely
beforeSend function (instrumentation-client.ts:35-71): Belt-and-suspenders filtering for edge cases that bypass ignoreErrors

2. Excellent Documentation & Context

Clear comments explaining each error pattern and why it should be filtered
Issue references ([Sentry] TypeError: Cannot assign to read only property 'pushState' of object '#<History>' #434, [Sentry] Hydration Error (replay) #437) linking to specific GitHub issues
Root cause explanations for browser extension conflicts and hydration mismatches

3. Performance Optimizations

Shared regex constant (instrumentation-client.ts:7): PUSHSTATE_REGEX prevents regex recompilation
Early filtering: ignoreErrors prevents unnecessary event processing
Development debugging (instrumentation-client.ts:64-66): Logs suppressed errors for visibility

⚠️ Issues & Recommendations

1. Code Duplication Between Filtering Layers

Problem: Error patterns are duplicated between ignoreErrors and beforeSend:

// In ignoreErrors (line 26):
"Text content does not match server-rendered HTML",

// In beforeSend (line 56):  
msg.includes("Text content does not match")

Impact: Maintenance burden, potential inconsistencies

Recommendation: Extract shared patterns to constants:

const ERROR_PATTERNS = {
  HYDRATION_MISMATCH: "Text content does not match server-rendered HTML",
  HYDRATION_FAILED: "Hydration failed because the server rendered HTML didn't match the client",
  // ...
} as const;

2. Inconsistent Pattern Matching Strategies

Problem: Mixed approaches between the two filtering layers:

ignoreErrors uses exact strings and precise regex
beforeSend uses loose includes() matching

Example (instrumentation-client.ts:56):

msg.includes("Text content does not match")  // Too broad

This could match legitimate errors containing that substring.

Recommendation: Use consistent, precise matching in both layers.

3. Undocumented React Error Codes

Problem: Magic numbers without context (instrumentation-client.ts:29-31):

"Minified React error #418",
"Minified React error #423", 
"Minified React error #425",

Recommendation: Add comments explaining what these specific error codes represent, or use descriptive constants.

4. Potential False Positive Risk

Problem: The Object Not Found Matching Id: regex (instrumentation-client.ts:33) uses a broad pattern that could match legitimate application errors.

Current: /Object Not Found Matching Id:\d+/

Recommendation: Consider more specific context or move to beforeSend only with additional validation.

🛡️ Security Assessment

✅ No Security Concerns

Error filtering only affects telemetry, not application behavior
No sensitive data exposure through error messages
Proper environment-based debug logging (development only)

🚀 Performance Impact

✅ Positive Impact

Reduces unnecessary Sentry event transmission and processing overhead
Early filtering with ignoreErrors is more efficient than beforeSend
String operations are lightweight for expected error volumes

📋 Test Coverage Recommendations

Missing Test Areas:

Unit tests for beforeSend filtering logic
Integration tests verifying Sentry configuration loads correctly
Mocking tests to ensure filtered errors don't reach Sentry

Suggested Test Structure:

// website/src/__tests__/sentry-filtering.test.ts
describe('Sentry Error Filtering', () => {
  it('should suppress React hydration errors', () => {
    const mockEvent = {
      exception: { values: [{ value: 'Text content does not match server-rendered HTML' }] }
    };
    expect(beforeSendFunction(mockEvent)).toBeNull();
  });

  it('should suppress pushState readonly errors', () => {
    const mockEvent = {
      exception: { values: [{ value: 'Cannot assign to read only property "pushState"' }] }
    };
    expect(beforeSendFunction(mockEvent)).toBeNull();
  });
});

🎯 Recommendations Summary

High Priority

Eliminate code duplication by extracting error patterns to shared constants
Standardize pattern matching approach across both filtering layers
Add unit tests for the filtering logic

Medium Priority

Document React error codes with explanations of what they represent
Review regex patterns for potential false positives
Consider environment-specific filtering (stricter patterns in production)

Low Priority

Add TypeScript interfaces for better type safety
Consider adding metrics to track filtering effectiveness

✅ Overall Assessment

This is a well-implemented solution that effectively addresses real Sentry noise issues. The approach demonstrates solid understanding of both Sentry filtering mechanisms and the specific error patterns being targeted.

Recommendation: ✅ Approve with minor improvements - The core implementation is sound, but addressing the code duplication and pattern consistency would strengthen maintainability.

The changes will significantly improve the signal-to-noise ratio in your Sentry monitoring without suppressing legitimate application errors.

Ajit Pratap Singh and others added 3 commits March 29, 2026 13:30

github-actions bot added the documentation Improvements or additions to documentation label Mar 29, 2026

vercel bot deployed to Preview March 29, 2026 09:22 View deployment

Merge branch 'main' into fix/sentry-noise-filters

36b8d02

vercel bot deployed to Preview March 29, 2026 10:01 View deployment

vercel bot deployed to Preview March 29, 2026 11:46 View deployment

Merge branch 'main' into fix/sentry-noise-filters

77b535b

vercel bot deployed to Preview March 29, 2026 12:21 View deployment

ajitpratap0 merged commit 155da55 into main Mar 29, 2026
21 checks passed

ajitpratap0 mentioned this pull request Mar 31, 2026

P0: Submit dev.to article to Hacker News + r/golang — top-of-funnel launch #442

Open

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(website): suppress Sentry hydration and pushState noise (#434 #437)#461

fix(website): suppress Sentry hydration and pushState noise (#434 #437)#461
ajitpratap0 merged 6 commits intomainfrom
fix/sentry-noise-filters

ajitpratap0 commented Mar 29, 2026

Uh oh!

vercel bot commented Mar 29, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Mar 29, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Mar 29, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Mar 29, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Mar 29, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

ajitpratap0 commented Mar 29, 2026

Summary

Fixes

Test plan

Uh oh!

vercel bot commented Mar 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: Sentry Noise Filtering

🔍 Review Summary

✅ Strengths

1. Defense in Depth Approach

2. Well-Documented Error Patterns

3. Performance Considerations

⚠️ Areas for Improvement

1. Code Quality Issues

2. Regex vs String Matching Inconsistency

3. Magic Numbers and Hardcoded Patterns

4. Potential False Positives

🛡️ Security Assessment

🚀 Performance Impact

📋 Test Coverage Recommendations

🎯 Final Recommendations

High Priority

Medium Priority

Low Priority

✅ Overall Assessment

Uh oh!

github-actions bot commented Mar 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Mar 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: Sentry Noise Filtering

🔍 Review Summary

✅ Strengths

1. Well-Architected Defense Strategy

2. Excellent Documentation & Context

3. Performance Optimizations

⚠️ Issues & Recommendations

1. Code Duplication Between Filtering Layers

2. Inconsistent Pattern Matching Strategies

3. Undocumented React Error Codes

4. Potential False Positive Risk

🛡️ Security Assessment

🚀 Performance Impact

📋 Test Coverage Recommendations

🎯 Recommendations Summary

High Priority

Medium Priority

Low Priority

✅ Overall Assessment

Uh oh!

github-actions bot commented Mar 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Review: Sentry Noise Filtering

🔍 Review Summary

✅ Strengths

1. Well-Architected Defense Strategy

2. Excellent Documentation & Context

3. Performance Optimizations

⚠️ Issues & Recommendations

1. Code Duplication Between Filtering Layers

2. Inconsistent Pattern Matching Strategies

3. Undocumented React Error Codes

4. Potential False Positive Risk

🛡️ Security Assessment

🚀 Performance Impact

📋 Test Coverage Recommendations

🎯 Recommendations Summary

High Priority

Medium Priority

Low Priority

✅ Overall Assessment

Uh oh!

Uh oh!

Reviewers

vercel bot commented Mar 29, 2026 •

edited

Loading

github-actions bot commented Mar 29, 2026 •

edited

Loading

github-actions bot commented Mar 29, 2026 •

edited

Loading

github-actions bot commented Mar 29, 2026 •

edited

Loading

github-actions bot commented Mar 29, 2026 •

edited

Loading