Skip to content

refactor(error-handling): centralize duplicate try/catch into Express error middleware#192

Open
Satvik77777 wants to merge 1 commit into
accordproject:mainfrom
Satvik77777:refactor/express-error-middleware
Open

refactor(error-handling): centralize duplicate try/catch into Express error middleware#192
Satvik77777 wants to merge 1 commit into
accordproject:mainfrom
Satvik77777:refactor/express-error-middleware

Conversation

@Satvik77777
Copy link
Copy Markdown
Contributor

Summary

The same try/catch → console.log → res.status(500) pattern
was duplicated 20+ times across agreements.ts, crud.ts,
and mcp.ts. Several console.log statements also exposed
PII and internal details to stdout. This PR centralizes
error handling into a single Express error middleware.

What this PR does

New file — server/middleware/errorHandler.ts

  • globalErrorHandler — single centralized error response
    location, replaces 20+ duplicate catch blocks
  • asyncHandler — wraps async route handlers to forward
    errors via next() without try/catch in every route
  • toSafeMessage — prevents stack traces and internal
    paths from leaking to API clients

Refactor — agreements.ts

  • Wrapped async route handlers with asyncHandler
  • Removed duplicate try/catch blocks
  • Removed console.log statements exposing:
    • req.body (user PII)
    • agreement.data and agreement.state (contract data)
    • err.stack (internal stack traces)

Refactor — crud.ts

  • Wrapped async route handlers with asyncHandler
  • Removed duplicate try/catch blocks
  • Removed console.log(sql.sql) and console.log(sql.params)
    which leaked raw SQL query structure to stdout

Refactor — mcp.ts

  • Removed console.log(req.body) on every MCP POST request
  • Replaced with structured console.error using
    non-sensitive context only

Why this matters

Security

Raw contract data, SQL queries, and stack traces were
being logged to stdout. In any hosted environment these
appear in server logs accessible to operators and
potentially leaked in log aggregation tools.

Maintainability

20+ identical catch blocks meant any change to error
handling required editing every handler file. Now
there is one place to update.

Reliability

asyncHandler ensures unhandled promise rejections in
route handlers are always caught and forwarded to
Express error handling — preventing silent process
crashes in Node.js.

References

Author Checklist

  • DCO sign-off provided
  • New middleware file with JSDoc
  • All existing tests passing
  • TypeScript compilation verified (npx tsc --noEmit)
  • No behavior changes — same error response shape

- Created globalErrorHandler and asyncHandler middleware

- Replaced duplicate try/catch blocks across agreements, crud, and mcp handlers

- Stripped raw SQL and full request bodies from stdout

- Ensured 500 JSON-RPC compatibility on /mcp initialization

Signed-off-by: Satvik77777 <satvikaini02@gmail.com>
@Satvik77777 Satvik77777 force-pushed the refactor/express-error-middleware branch from 77f62d6 to 81a999c Compare June 6, 2026 13:54
@Satvik77777
Copy link
Copy Markdown
Contributor Author

Hi @niallroche @mttrbrts — this PR centralizes the
duplicate try/catch pattern (repeated 20+ times across
agreements.ts, crud.ts, mcp.ts) into a single Express
error middleware. Also removes PII-exposing console.log
statements that were logging raw contract data and SQL
queries to stdout. All tests passing, DCO signed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Title: refactor(error-handling): centralize duplicate try/catch blocks into Express error middleware

1 participant