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

Inizia in Startup.AddGraphQLService, dove secondo quanto riferito ModifyCostOptions non viene chiamato, e ispeziona la gestione di runtime.graphql per l'impostazione depth-limit esistente. Riproduci il problema inviando tramite POST una query con una variabile di filtro a /graphql dopo dab init, quindi verifica che il comportamento dei costi sia configurabile e che i filtri validi forniti tramite variabili non falliscano più inaspettatamente 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)