GraphQL catalog has no runtime validation against the actual database schema

[ccisnedev]

Problem

The GraphQL catalog (buildSorteoCatalog or equivalent) is written manually by the developer. It describes tables, columns, and types as they are expected to exist in the database. However, there is no mechanism that validates this catalog against the actual schema at startup or query time.

If a column is added, renamed, or removed in PostgreSQL but the catalog is not updated, the GraphQL schema will silently diverge from reality. Queries against missing or renamed columns will either return nulls, produce runtime errors, or — worse — succeed with stale data.

Impact

• Silent data inconsistency in production
• No warning at startup when catalog and DB are out of sync
• Developer must remember to update two places (DB migration + catalog) manually

Proposed solution

One or more of the following:

1. Schema introspection at startup — query information_schema.columns on boot and compare against declared PhysicalField entries. Log a warning (or fail fast) for any mismatch.
2. Code generation from SQL schema — generate PhysicalObject declarations from the database schema or from migration files (e.g. pgschema, Flyway, Liquibase artifacts), eliminating the manual sync entirely.
3. CI contract test — a test that runs against a real DB instance and asserts that every declared catalog field exists and has the declared type.

Option 2 is the most robust long-term solution and removes the manual step entirely.

Related

• Roadmap item: "Generación de catalog GraphQL desde schema"
• Affects: modular_api GraphQL runtime, all language SDKs that expose a catalog API