fix: let VALIDATION_ERROR messages reach the client in production

The errorHandler middleware was unconditionally rewriting every
VALIDATION_ERROR to the generic 'Invalid request' string in production,
which silently neutralized the whole field-aware validation work from
the previous commit. Live curl showed "Invalid request" on the wire
even after the controllers were wired to formatZodError.

Added PASS_THROUGH_CODES — a small allow-list of error codes whose real
message is safe to expose. VALIDATION_ERROR is the only entry: its
messages are written by formatZodError and contain only the field name,
expected format, and the shape (not content) of what the client just
submitted. Nothing the client doesn't already know; no internal state
leaked.

All other codes keep the existing sanitize-in-production behavior
(generic message from the map, or 'An error occurred' for unknown
codes). 2 new middleware tests lock both sides in: VALIDATION_ERROR
propagates verbatim in production, NOT_FOUND still masks.

Author: proofoftrust21

src/middleware/errorHandler.ts

@@ -5,6 +5,10 @@ import { AppError } from '../errors';
 import { config } from '../config';
 import { logger } from '../logger';
 
+// In production, messages for known error codes are replaced with sanitized
+// versions so internal detail never reaches the client; unknown codes fall
+// back to 'An error occurred'. See PASS_THROUGH_CODES below for the explicit
+// whitelist of error codes that propagate the real message verbatim.
 const GENERIC_MESSAGES: Record<string, string> = {
   NOT_FOUND: 'Resource not found',
   VALIDATION_ERROR: 'Invalid request',
@@ -13,9 +17,16 @@ const GENERIC_MESSAGES: Record<string, string> = {
   PAYMENT_REQUIRED: 'Payment required',
 };
 
+// Codes whose real message is SAFE to expose to the client in production.
+// VALIDATION_ERROR messages are written by formatZodError and contain only
+// the field name, expected format, and the shape (not content) of the value
+// the client just submitted — nothing the client doesn't already know.
+const PASS_THROUGH_CODES = new Set(['VALIDATION_ERROR']);
+
 export function errorHandler(err: Error, req: Request, res: Response, _next: NextFunction): void {
   if (err instanceof AppError) {
-    const message = config.NODE_ENV === 'production'
+    const shouldSanitize = config.NODE_ENV === 'production' && !PASS_THROUGH_CODES.has(err.code);
+    const message = shouldSanitize
       ? (GENERIC_MESSAGES[err.code] ?? 'An error occurred')
       : err.message;
 

src/tests/middleware.test.ts

@@ -165,6 +165,65 @@ describe('errorHandler', () => {
     const body = res._body as { error: { code: string; message: string } };
     expect(body.error.message).toBe('Detailed dev error info');
   });
+
+  it('propagates the real VALIDATION_ERROR message in production', async () => {
+    // VALIDATION_ERROR is on the pass-through allow-list: messages come from
+    // formatZodError and are explicitly written for the client, so the
+    // generic "Invalid request" must NOT mask them in production.
+    vi.doMock('../config', () => ({
+      config: { NODE_ENV: 'production' },
+    }));
+    vi.doMock('../logger', () => ({
+      logger: { error: vi.fn() },
+    }));
+
+    const { errorHandler } = await import('../middleware/errorHandler');
+    const { ValidationError } = await import('../errors');
+    const res = mockRes();
+
+    errorHandler(
+      new ValidationError('caller must be a 64-char SHA256 hash or 66-char Lightning pubkey (02/03 prefix), got 11 chars'),
+      mockReq(),
+      res as unknown as Response,
+      vi.fn() as unknown as NextFunction,
+    );
+
+    expect(res._status).toBe(400);
+    const body = res._body as { error: { code: string; message: string } };
+    expect(body.error.code).toBe('VALIDATION_ERROR');
+    expect(body.error.message).toContain('caller');
+    expect(body.error.message).toContain('got 11 chars');
+    expect(body.error.message).not.toBe('Invalid request');
+  });
+
+  it('still masks NOT_FOUND messages in production', async () => {
+    // Spot-check that the generic-messages behavior still applies to codes
+    // NOT on the pass-through list, so the pass-through doesn't leak to
+    // other error types.
+    vi.doMock('../config', () => ({
+      config: { NODE_ENV: 'production' },
+    }));
+    vi.doMock('../logger', () => ({
+      logger: { error: vi.fn() },
+    }));
+
+    const { errorHandler } = await import('../middleware/errorHandler');
+    const { NotFoundError } = await import('../errors');
+    const res = mockRes();
+
+    errorHandler(
+      new NotFoundError('SecretInternalResource', 'hidden-id'),
+      mockReq(),
+      res as unknown as Response,
+      vi.fn() as unknown as NextFunction,
+    );
+
+    expect(res._status).toBe(404);
+    const body = res._body as { error: { code: string; message: string } };
+    expect(body.error.code).toBe('NOT_FOUND');
+    expect(body.error.message).toBe('Resource not found');
+    expect(body.error.message).not.toContain('SecretInternal');
+  });
 });
 
 describe('OpenAPI spec auth alignment', () => {