99designs/gqlgen

We use the schema: directive of gqlgen.yml extensively to load shared types and directives. In fact we've used it so extensively that we now have an entire dependency tree. Example: shared_directive.graphql: directive @product( name: String! ) on ENUM_VALUE shared_type.graphql: enum FeedbackType { ANSWER, COMMENT @product(name: "myproduct") } gqlgen.yml: schema: - shared_directive.graphql - shared_type.graphql - schema.graphql We only use @product in shared_type.graphql, not in schema.graphql; we need to remember to add shared_directive.graphql in gqlgen.yml even though gqlgen.yml does not use shared_directive.graphql directly. This is brittle and hard for devs to fiagure out what actually needs to be included in the schema: directive. The ask: Add support for an #include directive in .graphql files. (Or #gqlgen_include, or whatever name makes sense.) This is a comment to most graphql parsers, but gqlgen reads it specially and uses it as an alternate way of loading

Hi, I'm trying to design a federated graphql architecture in which entities can resolve @requires fields that take an array of objects, then resolve them in an efficient way without using the dataloaders pattern. The key issue would be that if a subgraph is to declare a new field that requires other fields that are arrays, e.g.: type Product @key(fields: "id") { id: ID! variations: [Variation!]! @external bestPrice: Float! @requires(variations { price }) } type Variation { price: Float! } is there a way to resolve bestPrice for multiple products in one entity resolution function call without encountering the N+1 problem? I've made multiple attempts using variations of explicit_requires, computed_requires, entity_resolver_multi and goField(batch: true) and shared the outcomes as of [email protected] in this repo: https://github.com/tobby-s/multi-entity-tests The examples are all runnable, there's a curl shared in the repo root to test on each of the examples to trigger debugging p

Hey team, A user recently scanned this repo using Qodo's AntiSlop Scanner. The analysis reviewed 10 recent PRs and found 22 issues, all confirmed to still exist on main. Here's one example: JSON null panics params (transports) Severity: action_required | Category: security In several transports, the body is decoded into a **graphql.RawParams (by passing &params) and then params is immediately dereferenced. A valid JSON body of null can set params to nil and cause a panic when assigning params.Headers/ReadTime (trivial DoS). How to validate: Send a POST request with a JSON body of null to any transport endpoint and observe the nil pointer panic. Agent prompt to fix: In each transport's request handler, add a nil check after JSON decoding: if params is nil after decode, return a 400 error instead of dereferencing it. Check all transports (HTTP POST, multipart, GET, etc.) for the same pattern. Other confirmed issues # Title Category PR 1 Incremental deletes outputs before genera

Summary When using the SSE transport with high-throughput subscriptions, multiple SSE events can be concatenated into a single data: line, breaking SSE protocol framing and causing downstream parsers to fail with "Invalid message" errors. Environment gqlgen version: v0.17.84 Go version: 1.21+ OS: Linux/macOS (observed in Kubernetes environment) frontend subscribe -> Wundergraph router -> subgraph subscription resolver <->channel of events Expected Behavior Each subscription event should be sent as a separate SSE frame: event: next data: {"data":{"mySubscription":{"field":"value1"}}} event: next data: {"data":{"mySubscription":{"field":"value2"}}} Actual Behavior Under high throughput, multiple events are concatenated on the same line and we receive on the event stream: event: next data: {"errors":[{"message":"Invalid message received"}],"data":null,"extensions":... This causes SSE parsers (including WunderGraph Cosmo router) to fail with "Invalid message received" errors because t