Metadata Rest API returns 500 for /objects and /fields

[Vloeck]

Bug Description

Possibly related to #16696
Twenty Version 2.1.0

When calling /rest/metadata/objects or /rest/metadata/fields, I get error code 500, no response body, no logs.
Happens on multi workspace mode and single workspace mode with my installation

other endpoints like /apiKeys, /webHooks, /views work fine

Expected behavior

calling api endpoints should work as described

Technical inputs

$ curl -v -H "Authorization: Bearer $TOKEN" $BASEURL'/rest/metadata/objects'
* Host twenty....:443 was resolved.
* IPv6: (none)
* IPv4: 192.168.178.103
*   Trying 192.168.178.103:443...
* Connected to twenty....(192.168.178.103) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  (...)
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://twenty..../rest/metadata/objects
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: twenty....]
* [HTTP/2] [1] [:path: /rest/metadata/objects]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [authorization: Bearer ey...pU]
> GET /rest/metadata/objects HTTP/2
> Host: twenty....
> User-Agent: curl/8.7.1
> Accept: */*
> Authorization: Bearer ey...pU
>
* Request completely sent off
< HTTP/2 500
< server: openresty
< date: Wed, 29 Apr 2026 19:03:23 GMT
< content-type: application/json; charset=utf-8
< content-length: 0
< x-powered-by: Express
< access-control-allow-origin: *
< access-control-expose-headers: WWW-Authenticate
< access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
< access-control-allow-headers: Origin, X-Requested-With, Content-Type, Accept
<
* Connection #0 to host twenty.... left intact

[sonarly]

🟠 Sonarly Analysis — High Severity

Missing exception filter on REST metadata controller causes silent 500 for /objects and /fields

The REST metadata controller for /objects and /fields endpoints lacks an exception filter and uses @res() decorator, causing any internal GraphQL proxy error to result in an empty HTTP 500 with no response body or logs.

Root Cause

The RestApiMetadataController at packages/twenty-server/src/engine/api/rest/metadata/rest-api-metadata.controller.ts is missing the @UseFilters(RestApiExceptionFilter) decorator that is present on the sibling RestApiCoreController. Combined with the use of @Res() decorator (which tells NestJS the controller manages the response directly), any exception thrown during request handling produces an empty HTTP 500 response with no body and no logs.

The /rest/metadata/objects and /rest/metadata/fields endpoints work fundamentally differently from /rest/metadata/apiKeys or /rest/metadata/webhooks. The objects/fields endpoints are handled by the wildcard RestApiMetadataController which proxies requests through an internal HTTP call to the GraphQL /metadata endpoint:

// rest-api-metadata.controller.ts - MISSING @UseFilters(RestApiExceptionFilter)
@Controller('rest/metadata/*path')
@UseGuards(JwtAuthGuard, WorkspaceAuthGuard, SettingsPermissionGuard(...))
export class RestApiMetadataController {
  @Get()
  async handleApiGet(@Req() request: Request, @Res() res: Response) {
    const result = await this.restApiMetadataService.get(request);
    res.status(200).send(cleanGraphQLResponse(result.data.data));
  }
}

Compare with the core controller which HAS the exception filter:

// rest-api-core.controller.ts - HAS exception filter
@Controller('rest')
@UseGuards(JwtAuthGuard, WorkspaceAuthGuard, CustomPermissionGuard)
@UseFilters(RestApiExceptionFilter)  // <-- This is missing from metadata controller
export class RestApiCoreController { ... }

The internal GraphQL proxy in RestApiService.call() has fragile error handling:

try {
  response = await httpClient.post(url, data, { ... });
} catch (err) {
  throw new RestApiException(err.response.data.errors);  // TypeError if err.response is undefined
}

If the internal HTTP call fails for any reason (connection refused, timeout, SSL mismatch, the server can't reach itself via SERVER_URL), err.response is undefined, causing err.response.data.errors to throw a TypeError. Without an exception filter, this TypeError becomes an empty 500.

The /rest/metadata/apiKeys and /rest/metadata/webhooks endpoints work because they have their own dedicated controllers (ApiKeyController, WebhookController) with @UseFilters(RestApiExceptionFilter) that directly call service methods without the GraphQL proxy pattern.

The triggering cause is the user's deployment configuration. The SERVER_URL environment variable (or its fallback from request.protocol + host) must resolve to a URL the server can reach itself at. In containerized deployments behind a reverse proxy (the user mentions openresty), the external hostname may not resolve back to the server from inside the container. This has always been a latent issue with the GraphQL proxy pattern, but it went undetected because the missing exception filter silently swallows all errors as empty 500 responses.

The fix requires two changes:

1. Add @UseFilters(RestApiExceptionFilter) to RestApiMetadataController
2. Fix the unsafe err.response.data.errors access in RestApiService.call() to handle cases where err.response is undefined

Blame commit: 9a80164c by FelixMalfait — Add comprehensive permission guard coverage across GraphQL and REST endpoints (#15739)

---

Analyzed by Sonarly · View full analysis

[paschembri]

Got the same error here: #20136

[deepakstar04]

Examine Worker Logs: Since the main server logs are empty, check the logs for your background workers or twenty-server container directly for any Uncompiled message detected or Database connection failures.
Test via API Playground: Go to Settings > API > Metadata REST and use the built-in playground to see if the error persists there. This helps determine if the issue is with your curl request structure or the server itself.

[Vloeck]

Worker logs are empty as well.

Playground is not helpful

[charlesBochet]

We are getting it in prod too, is it flaky on your side or always the case?

[charlesBochet]

Working on it with @Weiko