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

Bắt đầu trong Startup.AddGraphQLService, nơi được báo cáo là ModifyCostOptions không được gọi, và kiểm tra cách xử lý runtime.graphql đối với thiết lập depth-limit hiện có. Tái hiện sự cố bằng cách POST một truy vấn có biến bộ lọc tới /graphql sau dab init, sau đó xác minh rằng hành vi chi phí có thể cấu hình được và các bộ lọc hợp lệ được cung cấp qua biến không còn bất ngờ thất bại với 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)