[P3] Eliminate silently swallowed errors via .catch(() => {})

[itsmiso-ai]

Problem: Multiple places in the codebase use .catch(() => {}) to silently discard errors. This hides failures during cleanup operations, JSON parsing, and release-lock calls, making debugging harder when things go wrong. While some of these are deliberate best-effort cleanup (releaseLock after a failure), even those should at minimum log a warning so operators can trace issues.

Evidence:

$ grep -rn "\.catch(() => {})" ./src --include="*.ts" --include="*.tsx" | grep -v node_modules

src/components/issue-card.tsx:159:  const data = await res.json().catch(() => ({}));
src/components/issue-card.tsx:213:  const data = await res.json().catch(() => ({}));
src/components/issue-card.tsx:266:  const data = await res.json().catch(() => ({}));
src/app/login/page.tsx:31:           .catch(() => {});
src/app/automation/page.tsx:200:     .catch(() => {});
src/app/api/automation/sync/route.ts:27:  const body = await request.json().catch(() => ({}));
src/app/api/automation/sync/route.ts:63:    await releaseLock(runId).catch(() => {});
src/app/api/sync/route.ts:73:       await releaseLock(runId).catch(() => {});
src/app/api/sync/scheduled/route.ts:188:  }).catch(() => {});
src/app/api/sync/scheduled/route.ts:190:  await releaseLock(runId).catch(() => {});

The production-critical silent swallows:

• releaseLock() catch in sync routes — if a lock release fails silently, subsequent sync runs may fail with lock-contention errors and the operator will not know why
• request.json().catch(() => ({})) — malformed JSON bodies silently become empty objects, potentially masking API misuse

Acceptance:

• Each .catch(() => {}) is replaced with appropriate error handling
• Best-effort cleanup (e.g., releaseLock after failure) uses .catch((e) => console.warn("Failed to release lock:", e))
• JSON parsing falls back to a sensible default but logs a warning: .catch((e) => { console.warn("Failed to parse JSON body:", e); return {}; })
• Client-side .catch(() => {}) in components at least logs: .catch((e) => console.error("Action failed:", e))
• All existing tests continue to pass

[itsmiso-ai]

Not worth doing yet

Items considered during this audit but intentionally excluded as not actionable right now:

1. GitHub App installation token caching — not using crypto.timingSafeEqual for token comparison

The github.ts module caches installation tokens but there is no constant-time comparison when validating them. Since tokens are compared against process.env values at runtime (not user-supplied input that could be timing-attacked), this is a non-issue for the current architecture.

2. extractLogExcerpt uses substring-based truncation

src/lib/github.ts:777 uses rawLog.substring(0, maxChars) which could split a multi-byte UTF-8 character. This is extremely unlikely to cause issues since GitHub CI logs are ASCII, and 6000 chars is generous. Worth fixing at P4+ if someone is touching that code path.

3. Prisma adapter URL contains the connection string directly

PrismaPg(url) is passed the raw DATABASE_URL. If someone enables query logging in production, the full connection string (including password) could leak. Mitigation: set log: ["error"] which is already the production default. No action needed.

4. Hardcoded GITHUB_API = "https://api.github.com" — no enterprise GitHub support

Dispatch assumes public GitHub API. If the organization ever moves to GitHub Enterprise Server, every fetchGitHub(...) call in github.ts would need to use a configurable base URL. This is premature generalization — no GHE requirement exists.

5. Module-level installationTokenCache is not evicted on env var changes

The singleton installationTokenCache in github.ts is never invalidated when env vars change. In a long-running pod this is fine since env vars are set at startup and never change. Hot-reload env var changes are not a supported Dispatch scenario.

6. as unknown as casts in prisma.ts proxy

The prisma lazy proxy in src/lib/prisma.ts uses as unknown as Record<PropertyKey, unknown> and as unknown as object casts. These are safely scoped to the proxy implementation and have no downstream impact. Refactoring would add complexity without benefit.

7. More extensive test coverage

While there are 24 untested source files, many are thin UI components (badge.tsx, input.tsx, button.tsx), empty facade files (per the #618/#655 reconciliation), or straightforward utility functions. Issue #654 already covers adding tests for high-risk modules. Further coverage of trivial components is P4 at best.

8. Converting console.error to structured logging

All error logging uses console.error instead of a structured logger. For a single-pod internal tool with less than 10 concurrent users, this is perfectly adequate. Worth revisiting if Dispatch scales significantly or if log aggregation becomes a requirement.

9. No health check on database connection startup

The /api/health endpoint checks the database on each request rather than maintaining a persistent connection health monitor. Since Prisma handles connection pooling and automatic reconnection, a startup check would add complexity with minimal benefit.