https://sonarly.com/issue/29560?type=bug
The `findManyApplications` GraphQL query fails when a client requests `applicationVariables` (or any of 4 other OneToMany relation fields), because the backend no longer loads those relations but the GraphQL schema still declares them as non-nullable.
Fix: The root cause is a schema-reality mismatch introduced by commit 9a95cd02ed (PR #19892, merged 2026-04-20). That PR intentionally removed OneToMany relation loading from `findManyApplications` to fix Cartesian product timeout issues, but neglected to update the GraphQL schema. Five `@Field()` decorators on ApplicationDTO declared OneToMany relation fields (agents, frontComponents, logicFunctions, objects, applicationVariables) as non-nullable, but multiple code paths return ApplicationDTO instances without those fields populated.
The fix adds `{ nullable: true }` to all five `@Field()` decorators, making the GraphQL schema accurately reflect that these fields are optionally loaded. This is consistent with the TypeScript type annotations (all five properties already had `?` optional markers) and with the existing pattern used by other optional fields in the same DTO (e.g., defaultLogicFunctionRole, applicationRegistration).
This resolves the Sentry error "Cannot return null for non-nullable field Application.applicationVariables" and prevents the same class of error for the other four relation fields. The fix is safe because: (1) the standard frontend FIND_MANY_APPLICATIONS query doesn't request these fields, (2) the frontend FIND_ONE_APPLICATION query does request them but that code path (findOneApplication) properly loads all relations via Promise.all, and (3) any third-party API consumers or SDK users will now get null instead of a hard GraphQL error when these fields aren't loaded.
Sonarly Claude Code
dfc0a4d5fc