Prevent metadata schema leakage into /graphql; disable GraphQL auto-discovery & speed up NestJS boot

[FelixMalfait]

Summary

The /graphql endpoint currently exposes metadata resolvers/types that should only appear under /metadata. This is caused by GraphQL auto‑discovery scanning a broad module tree, which also contributes to slower NestJS boot times.

We should disable auto‑discovery for core GraphQL and move to explicit schema construction, while keeping resolvers co‑located with services. For metadata, we should also create an explicit schema from a central resolver list.

Background / Evidence

• Core GraphQL is configured with autoSchemaFile: true and include: [CoreEngineModule], which causes Nest/Yoga to scan the entire module graph for resolvers. That module graph includes metadata modules, so metadata resolvers get pulled into /graphql. (packages/twenty-server/src/engine/api/graphql/graphql-config/graphql-config.service.ts; packages/twenty-server/src/engine/core-modules/core-engine.module.ts)
• The /metadata endpoint uses the same auto‑discovery pattern via autoSchemaFile and include, pointing at MetadataGraphQLApiModule, which itself imports MetadataEngineModule (thereby scanning metadata resolvers). (packages/twenty-server/src/engine/api/graphql/metadata.module-factory.ts; packages/twenty-server/src/engine/api/graphql/metadata-graphql-api.module.ts)
• We already build the core workspace schema explicitly using WorkspaceSchemaFactory + makeExecutableSchema, so core GraphQL can work without discovery if we stop enabling it in config. (packages/twenty-server/src/engine/api/graphql/workspace-schema.factory.ts)

Goals

1. Stop /graphql from exposing metadata schema.
2. Remove GraphQL auto‑discovery for the core endpoint and rely on explicit schema building.
3. Keep resolvers close to services (no per‑resolver modules).
4. Improve startup time by avoiding deep module graph scans.

Proposed Approach

✅ Core /graphql (explicit only)

• Remove autoSchemaFile: true and include: [CoreEngineModule] from core GraphQL config.
• Ensure the schema comes only from the existing conditionalSchema path that uses WorkspaceSchemaFactory.
• This eliminates Nest’s resolver scanning for core GraphQL entirely, preventing metadata bleed‑through and speeding startup.

Files involved:

• packages/twenty-server/src/engine/api/graphql/graphql-config/graphql-config.service.ts (remove auto‑discovery config, rely on conditional schema).
• packages/twenty-server/src/engine/api/graphql/workspace-schema.factory.ts (already builds schema explicitly; no changes expected unless needed).

✅ Metadata /metadata (explicit resolver list, no auto‑discovery)

• Keep resolvers where they are, but create a single centralized resolver list and build the metadata schema explicitly.
• Replace autoSchemaFile + include with an explicit schema build (e.g., buildSchema or Nest GraphQLSchemaFactory, depending on existing stack).
• Import service modules as needed for DI, but do not scan the module graph for resolvers.

Files involved:

• packages/twenty-server/src/engine/api/graphql/metadata.module-factory.ts (remove autoSchemaFile & include, provide explicit schema).
• packages/twenty-server/src/engine/api/graphql/metadata-graphql-api.module.ts (keep module wiring; update to use explicit schema instead of auto‑discovery).

Acceptance Criteria

• /graphql introspection shows no metadata types or resolvers.
• /metadata continues to expose all metadata types/resolvers as before.
• Boot time improves or at least no longer worsens due to GraphQL scanning.
• No per‑resolver modules introduced; resolvers remain close to services.

Optional Tests / Checks

• Add an integration test that introspects /graphql and asserts metadata types (e.g., ObjectMetadata, FieldMetadata) are absent.
• Add a complementary test for /metadata asserting those types are present.

Notes

This change doesn’t require reorganizing resolvers into per‑resolver modules. The main shift is from auto‑discovery to explicit schema composition, which also reduces Nest’s module scanning overhead and makes schema boundaries explicit.

[FelixMalfait]

@claude can you tackle this. Make sure to create comprehensive tests and iterate until all tests are passing

[claude]

Claude encountered an error after 12m 8s —— View job

---

Tackling Issue #17638: Prevent metadata schema leakage & disable GraphQL auto-discovery

• Gather context — read relevant source files
• Modify core /graphql config to remove auto-discovery of metadata resolvers
• Modify metadata /metadata to use explicit schema building
• Add comprehensive tests for schema isolation
• Set up dev environment and run tests
• Iterate until all tests pass
• Commit and push changes

Changes so far:

1. Created CoreResolversModule — aggregates only core resolver modules (excludes metadata modules like RoleModule, WebhookModule, PageLayoutModule)
2. Updated GraphQLConfigService to use CoreResolversModule instead of CoreEngineModule as the include target
3. Created centralized metadataResolvers list for explicit metadata schema construction
4. Updated metadataModuleFactory to build schema explicitly via GraphQLSchemaFactory.create() instead of autoSchemaFile
5. Updated MetadataGraphQLApiModule to import GraphQLSchemaBuilderModule and inject GraphQLSchemaFactory

[FelixMalfait]

@claude try again

[claude]

Claude finished @FelixMalfait's task in 13m 1s —— View job • claude/issue-17638-20260202-1627 • Create PR ➔

---

Tackling Issue #17638: Prevent metadata schema leakage & disable GraphQL auto-discovery

• Gather context — read relevant source files
• Modify core /graphql config to remove auto-discovery
• Modify metadata /metadata to use explicit schema building
• Add comprehensive tests for schema isolation
• Set up dev environment and run tests (typecheck, lint, 19 unit tests all passing)
• Iterate until all tests pass
• Commit and push changes

Summary of changes:

1. graphql-config.service.ts — Removed autoSchemaFile: true, include: [CoreEngineModule], and orphaned types config. Schema now comes exclusively from conditionalSchema via WorkspaceSchemaFactory, eliminating metadata resolver scanning from the core /graphql endpoint.

2. metadata-resolvers.ts (new) — Centralized list of all 23 metadata resolver classes. New resolvers should be added here to be included in the /metadata schema.

3. metadata.module-factory.ts — Replaced autoSchemaFile + include: [MetadataGraphQLApiModule] with explicit schema via GraphQLSchemaFactory.create(metadataResolvers). No more auto-discovery scanning.

4. metadata-graphql-api.module.ts — Added GraphQLSchemaBuilderModule import and GraphQLSchemaFactory injection to support explicit schema building.

5. Tests:

   • graphql-config.service.spec.ts — Verifies core config has no autoSchemaFile, include, or buildSchemaOptions
   • metadata.module-factory.spec.ts — Verifies metadata builds schema explicitly via GraphQLSchemaFactory
   • metadata-resolvers.spec.ts — Verifies resolver list is complete, has no duplicates, and excludes core resolvers
   • schema-isolation.integration-spec.ts — Integration test verifying /graphql doesn't leak metadata types and /metadata still exposes them

·