Remove Debug console.log Statements from Production Code

[pragmaticAweds]

Context & Impact

There are 41+ console.log and console.error statements scattered across the production codebase — in services, hooks, components, and providers. These include sensitive debug output like console.log('Creating stream', params), console.log('Distributing', params), and console.log('Fetching stream ${streamId}'). This data is visible in any user's browser DevTools.

Why this matters: Debug logging in production leaks implementation details, transaction parameters, and internal state to anyone who opens the browser console. In a financial application, this is both a security concern and a sign of incomplete release hygiene. It also clutters the console, making legitimate error tracking harder.

Scope

• Audit and remove all console.log statements from production code
• Replace critical console.error calls with proper error handling (toasts, error boundaries, or error reporting)
• Keep only intentional, structured logging (if any) behind a debug flag or environment check
• Ensure no transaction parameters, wallet addresses, or internal state are logged in production

Implementation Guidelines

• Search the entire apps/web/src/ directory for console.log, console.warn, console.error, and console.debug
• For each occurrence, decide: remove entirely, replace with toast notification, or guard behind process.env.NODE_ENV === 'development'
• console.error in catch blocks should be replaced with user-facing error handling (see error notification issue)
• Consider adding an ESLint rule (no-console) to prevent future regressions
• Do NOT remove logging from test files — only production source code

Acceptance Criteria

• Zero console.log statements remain in apps/web/src/ (excluding test files)
• All console.error in catch blocks are replaced with proper error handling or guarded behind dev check
• No transaction parameters, wallet addresses, or stream IDs are logged in production
• An ESLint no-console rule is configured (with warn level) to prevent future regressions
• The app functions correctly after removal — no logic depended on console side effects
• Test files are unaffected

Getting Started

1. Run grep -rn "console\.\(log\|error\|warn\|debug\)" apps/web/src/ --include="*.ts" --include="*.tsx" | grep -v "test\." to find all instances
2. Categorize each: remove, replace with toast, or guard behind dev check
3. Start with services/stellar.service.ts (largest concentration)
4. Move to hooks, then components, then providers
5. Add no-console rule to eslint.config.mjs
6. Run pnpm build and pnpm lint to verify nothing is broken
7. Test core flows (stream creation, distribution, wallet connect) to confirm no regressions

---

PR Submission Guide

This section applies to every PR for this issue. Follow it exactly.

Before You Start

• Pull the latest main branch: git checkout main && git pull origin main
• Create your feature branch from main: git checkout -b fix/<issue-number>-remove-console-logs

While Working

• Make atomic commits — one concern per commit, each commit must build
• Use Conventional Commits: feat(scope): description, fix(scope): description
• Keep your branch up to date: git pull origin main --rebase regularly

Before Submitting the PR

• Pull latest main and rebase: git checkout main && git pull origin main && git checkout <your-branch> && git rebase main
• Ensure the build passes: pnpm build
• Ensure linting passes: pnpm lint
• Record a screen recording of your implementation showing the feature/fix working in the browser. Attach it to the PR.

PR Requirements

• Link this issue in your PR description using Closes #<issue-number>
• Fill out the full PR template — Summary, What Was Implemented, Implementation Details, How to Test
• Attach your screen recording demonstrating the implementation
• Request a review from a maintainer

PRs without a screen recording or without a linked issue will not be reviewed. Failure to meet PR requirements may lead to PR rejection.

[1sraeliteX]

@1sraeliteX has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

I would like to work on this issue. My plan:

• Audit all console.log, console.warn, console.error, and console.debug statements in apps/web/src/ excluding test files
• Remove all console.log statements entirely, starting with the largest concentration in stellar.service.ts then moving to hooks, components, and providers
• Replace console.error in catch blocks with user-facing toast notifications or guard them behind a process.env.NODE_ENV === 'development' check where logging is genuinely useful for debugging
• Ensure no transaction parameters, wallet addresses, stream IDs, or internal state remain logged in production
• Add a no-console ESLint rule at warn level in eslint.config.mjs to prevent future regressions
• Verify core flows including stream creation, distribution, and wallet connect work correctly after removal

Tests will confirm zero console.log statements remain in production source, catch block errors surface correctly via toasts, and the ESLint rule flags any new console usage.

Branch: fix/remove-console-logs
Commit: fix(cleanup) remove debug console statements and add no-console ESLint rule
PR will include: Closes 36, full PR template, and a screen recording showing a clean browser console during wallet connection and transaction flows.

Please assign, happy to clarify any catch block decisions before starting.

Thanks!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @1sraeliteX to this issue.