GraphQL schema build crashes on MDR names with invalid GraphQL characters (e.g. hyphen)

[bjagg]

Describe the bug

graphql-org1 (dev) is crash-looping. On startup it loads the OpenAPI schema from MDR (data model 17, 200 OK) and then fails building the Strawberry/GraphQL schema:

generate_graphql_schema -> strawberry Schema(...) -> GraphQLSchema(...)
graphql.error.graphql_error.GraphQLError:
    Names must only contain [_a-zA-Z0-9] but 'iSO639-2LangCode' does not.
ERROR  Application startup failed. Exiting.   (container exit code 3)

ECS then restarts it → it crashes again → running 0 / desired 1 → the ALB returns 503 for every request to https://graphql-org1.dev.lif.unicon.net.

Root cause

components/lif/openapi_to_graphql/type_factory.py exposes the raw MDR schema name as the GraphQL name — e.g. strawberry.field(name=field_name, …) (line ~318, and ~8 other field/type/enum sites). GraphQL identifiers must match /[_A-Za-z][_0-9A-Za-z]*/. An MDR attribute named iSO639-2LangCode (hyphen) is therefore an illegal GraphQL name, and a single bad name fails the entire schema build — taking the whole service down. safe_identifier is applied to the Python attribute name but not to the exposed GraphQL name.

So any MDR element whose name contains an invalid character (or leads with a digit) can hard-down GraphQL. (Likely the concrete instance behind the spike #369; also a naming-convention violation per docs/specs/data-model-rules.md — no hyphens.)

Fix

Harden openapi_to_graphql so an invalid MDR name can never crash schema build: sanitize names to valid GraphQL identifiers at every GraphQL-name boundary (field names, object/array sub-type names, enum type names), with a case-preserving sanitizer (distinct from safe_identifier, which snake-cases for Python). Add regression coverage.

Immediate workaround (data): rename the offending MDR element iSO639-2LangCode → a GraphQL-safe name (e.g. iso6392LangCode) in data model 17; graphql-org1 recovers on next restart.

Context: surfaced while verifying the LDE dev deploy (#998). Separate from PR #1010 (LDE client timeouts).

[bjagg]

The sanitization fix (#1012) and the data rename are complementary — both are needed.

Traced the full data path (GraphQL resolver → Query Planner selected_fields → response key mapping → MCP). Conclusion:

• Issue #1011: harden GraphQL schema build against invalid source names #1012 recovers everything valid. safe_graphql_name is identity on valid names, so the generated GraphQL schema is byte-for-byte unchanged for healthy fields — GraphQL, the QP selected_fields/filter names, and MCP all behave exactly as before. Its job is to stop one malformed name from crashing the whole service (which had taken graphql-org1 down in both dev and demo).

• Issue #1011: harden GraphQL schema build against invalid source names #1012 does NOT make the offending field functional. iSO639-2LangCode is name-inconsistent across the stack regardless of sanitization:

  layer	name
  GraphQL exposed (post-Issue #1011: harden GraphQL schema build against invalid source names #1012)	iSO639_2LangCode
  dataclass attr (safe_identifier)	i_so639_2_lang_code
  QP response key (to_snake_case)	i_so639-2_lang_code (hyphen kept)

  The attr ≠ the snake'd QP key, and the selected_fields GraphQL sends QP (iSO639_2LangCode) won't match the data source's actual iSO639-2LangCode. So that field is present-but-null — it never round-tripped data end-to-end.

Action still required (data): rename the MDR element iSO639-2LangCode → a valid camelCase name (e.g. iso6392LangCode) in both dev and demo data models. With no hyphen, safe_identifier/to_snake_case/the QP key all agree and the field flows correctly through GraphQL, QP, and MCP. #1012 is the safety net; this rename is the actual fix for the field.