fix: add error handling wrapper for graphqlUploadExpress middleware

[MaxGhenis]

Summary

This PR adds error handling around the graphqlUploadExpress() middleware to improve error responses for multipart upload failures.

Problem

When multipart upload parsing fails, errors are returned in Express format ({"error": {...}}) instead of GraphQL format ({"errors": [...]}). This makes it harder for GraphQL clients to parse error responses.

Solution

Wrap the graphqlUploadExpress() middleware with error handling that:

1. Catches any errors from the middleware
2. Logs the actual error for debugging
3. Returns a properly formatted GraphQL error response
4. Returns HTTP 400 instead of 500 for parsing errors

Testing

Added tests in test/server/routes/graphql.test.ts that verify:

1. Malformed multipart requests (invalid JSON) return 400 with GraphQL-formatted errors
2. Valid multipart uploads return GraphQL-formatted responses (not 500)

Note

This improves error formatting. The root cause of the 500 errors reported in opencollective/opencollective#8456 appears to be production-environment specific (see investigation comment).

🤖 Generated with Claude Code

[sentry]

Bug: The error handling callback for graphqlUploadExpress is never called because the middleware uses next(error) to propagate errors, bypassing the intended logic.
_{Severity: CRITICAL | Confidence: High}

🔍 Detailed Analysis

The middleware wrapper for graphqlUploadExpress uses a callback (err) => {...} to handle file upload errors. However, the graphqlUploadExpress middleware follows the standard Express.js error handling pattern by calling next(error) upon failure. This bypasses the custom callback entirely, meaning the error handling logic within it will never be executed. As a result, file upload parsing errors will not be formatted as GraphQL responses and will instead be passed to the global error handler, defeating the purpose of the change.

💡 Suggested Fix

Remove the custom callback. Instead, pass next directly to the uploadMiddleware and let errors propagate to the standard Express error-handling middleware. The graphqlUploadExpress middleware should be invoked as uploadMiddleware(req, res, next); to allow Express to correctly route errors.

🤖 Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: server/routes.ts#L313-L316

Potential issue: The middleware wrapper for `graphqlUploadExpress` uses a callback
`(err) => {...}` to handle file upload errors. However, the `graphqlUploadExpress`
middleware follows the standard Express.js error handling pattern by calling
`next(error)` upon failure. This bypasses the custom callback entirely, meaning the
error handling logic within it will never be executed. As a result, file upload parsing
errors will not be formatted as GraphQL responses and will instead be passed to the
global error handler, defeating the purpose of the change.

_{Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 8139129}

[MaxGhenis]

Closing this PR - Sentry correctly identified that the callback pattern doesn't work with Express middleware (graphqlUploadExpress uses next(error) which bypasses the callback).

More importantly, the root cause has been identified and fixed in the frontend: opencollective/opencollective-frontend#11773

The frontend GraphQL proxy was corrupting multipart requests by JSON-stringifying them. That PR fixes the proxy to forward multipart bodies as raw Buffers, which resolves the file upload issue without needing changes to the API.