Audit the codebase for silent error handling (empty catch blocks, swallowed errors) and establish a consistent error logging strategy using Sentry/GlitchTip.

Why

• Silent failures hide bugs and make debugging difficult

• Empty catch blocks violate ESLint rules (requires disable comment)

• No visibility into production errors without logging

• Sentry/GlitchTip integration already exists but may be underutilized

• Errors should be logged for observability, even if UI gracefully handles them

Context

Example of silent failure (attached)

Sentry/GlitchTip is already configured:

• src/shared/sentry.js — integration exists

• Stage DSN: glitchtip.devshift.net/41

• Prod DSN: glitchtip.devshift.net/42

Acceptance Criteria

• [ ] Audit codebase for empty catch blocks and silent error handling patterns:

• • [ ] Empty catch {} blocks

• • [ ] catch (e) { /* ignored */ }

• • [ ] .catch(() => {}) promise handlers

• [ ] Document each instance with file, line number, and context

• [ ] Categorize errors by severity (critical vs. recoverable)

• [ ] Evaluate current Sentry/GlitchTip helper utilities in src/shared/sentry.js

• [ ] Determine if additional helper functions are needed (e.g., captureException wrapper)

• [ ] Define error logging conventions:

• • [ ] What context/metadata to include

• • [ ] When to log vs. when to rethrow

• • [ ] Error grouping strategy

• [ ] Verify GlitchTip is receiving errors (check dashboard access)

• [ ] Produce implementation tickets with effort estimates

• [ ] Document recommended error handling patterns for developers