[Bug]: 2.0 rejects filter-variable queries with HC0047; Hot Chocolate cost limits are not configurable

Comienza en Startup.AddGraphQLService, donde según se informa no se llama a ModifyCostOptions, e inspecciona el manejo de runtime.graphql para la configuración existente de depth-limit. Reproduce el problema enviando mediante POST una consulta con una variable de filtro a /graphql después de dab init; luego verifica que el comportamiento de los costes sea configurable y que los filtros válidos proporcionados mediante variables ya no fallen inesperadamente con HC0047.

[Bug]: 2.0 GA rejects filter: $variable queries with HC0047 — cost limits are not configurable

What happened?

After upgrading from 1.7.93 to 2.0.8, every query that passes a whole filter input as a GraphQL variable fails with:

{
  "errors": [{
    "message": "The maximum allowed field cost was exceeded.",
    "extensions": { "code": "HC0047", "fieldCost": 1325, "maxFieldCost": 1000 }
  }]
}

Hot Chocolate 16 (bundled since 2.0) enables static cost analysis by default with MaxFieldCost = 1000, and DAB exposes no configuration for it — runtime.graphql only has depth-limit; ModifyCostOptions is never called in Startup.AddGraphQLService.

Why this breaks virtually every real client

Generated *FilterInput types are self-referential (and: [XFilterInput!], or: [XFilterInput!]). When a filter is supplied as a variable, the cost analyzer prices the input type's recursive worst case, not the actual value. Measured against a DAB 2.0.8 instance (MSSQL, 131 entities) using GraphQL-Cost: validate:

The ~1200 floor is entity-independent — a 3-column lookup table's filter variable prices at ~1202 — so every filter: $variable query exceeds the 1000 default. In our app that's 79 call sites across 48 routes, i.e. every list page. filter: $variable is the natural pattern for dynamic filtering (and what most GraphQL client codegen produces), and it worked on 1.x.

Related upstream: ChilliCream/graphql-platform#9548 (cost assumes two levels of recursion for circular references).

Expected

Either (preferably both):

1. runtime.graphql config for cost analysis — e.g. cost: { enforce: bool, max-field-cost: int, max-type-cost: int } — mirroring the existing depth-limit knob.
2. Defaults that don't reject variable-supplied filters on every entity (e.g. enforcement off unless configured, or variable inputs priced by provided value rather than recursive worst case).

Steps to reproduce

1. dab init against any MSSQL database, add any table entity, start DAB 2.0.8.
2. POST /graphql with query Q($f: <Entity>FilterInput) { <entities>(filter: $f) { items { __typename } } } and any (or no) variable value.
3. Observe HC0047 with fieldCost ≈ 1200+ vs maxFieldCost 1000.

Version

2.0.8 (the v2.0.9 tag contains no cost-related changes, so it is equally affected)

What database are you using?

Azure SQL / SQL Server

What hosting model are you using?

Container (App Service)