Reproduction of failing conditional root field planning

[ardatan]

No description provided.

[github-actions]

✅ k6-benchmark results

     ✓ response code was 200
     ✓ no graphql errors
     ✓ valid response structure

     █ setup

     checks.........................: 100.00% ✓ 215313      ✗ 0    
     data_received..................: 6.3 GB  209 MB/s
     data_sent......................: 84 MB   2.8 MB/s
     http_req_blocked...............: avg=3.3µs    min=531ns  med=1.52µs  max=11.55ms  p(90)=2.19µs  p(95)=2.56µs  
     http_req_connecting............: avg=893ns    min=0s     med=0s      max=2.69ms   p(90)=0s      p(95)=0s      
     http_req_duration..............: avg=20.45ms  min=2.4ms  med=19.48ms max=152.43ms p(90)=27.93ms p(95)=31.2ms  
       { expected_response:true }...: avg=20.45ms  min=2.4ms  med=19.48ms max=152.43ms p(90)=27.93ms p(95)=31.2ms  
     http_req_failed................: 0.00%   ✓ 0           ✗ 71791
     http_req_receiving.............: avg=146.85µs min=21.1µs med=37.34µs max=120.77ms p(90)=88.41µs p(95)=376.76µs
     http_req_sending...............: avg=24.49µs  min=4.47µs med=9.75µs  max=23.3ms   p(90)=14.93µs p(95)=28.1µs  
     http_req_tls_handshaking.......: avg=0s       min=0s     med=0s      max=0s       p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=20.28ms  min=2.35ms med=19.36ms max=90.13ms  p(90)=27.67ms p(95)=30.87ms 
     http_reqs......................: 71791   2387.506218/s
     iteration_duration.............: avg=20.89ms  min=6.54ms med=19.81ms max=244.6ms  p(90)=28.35ms p(95)=31.67ms 
     iterations.....................: 71771   2386.841091/s
     vus............................: 50      min=50        max=50 
     vus_max........................: 50      min=50        max=50 

[github-actions]

🐋 This PR was built and pushed to the following Docker images:

Image Names: ghcr.io/graphql-hive/router

Platforms: linux/amd64,linux/arm64

Image Tags: ghcr.io/graphql-hive/router:pr-602 ghcr.io/graphql-hive/router:sha-d6748f8

Docker metadata

{
"buildx.build.ref": "builder-6bc559ef-a9f0-45e8-9512-49a5ed6441ef/builder-6bc559ef-a9f0-45e8-9512-49a5ed6441ef0/6t06rfu8bp1vviely5m4xv40m",
"containerimage.descriptor": {
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "digest": "sha256:8fa922ee4a73d93125937811511f74b6c2d8346f4c88226c8628c1a71f636298",
  "size": 1609
},
"containerimage.digest": "sha256:8fa922ee4a73d93125937811511f74b6c2d8346f4c88226c8628c1a71f636298",
"image.name": "ghcr.io/graphql-hive/router:pr-602,ghcr.io/graphql-hive/router:sha-d6748f8"
}

[ardatan]

@gemini-code-assist Any idea how to fix?

[gemini-code-assist]

@ardatan Thanks for reaching out! It looks like this pull request is designed to reproduce a failing scenario for conditional root field planning, which is a great first step towards a fix. The insta::assert_snapshot!(format!("{}", query_plan), @r#""#); line suggests that the query_plan is currently empty or not generating the expected output when formatted.

To help diagnose and fix the "failing conditional root field planning," here are a few areas you might want to investigate:

1. Inspect the query_plan object: Before the insta::assert_snapshot!, try to log or inspect the query_plan object directly. This will give you insight into what the planner is actually producing, rather than just its string representation. Is it an empty plan, or a plan that doesn't include the productRecommender field?

2. Directive Handling in Query Planner:

   • @include logic: Review the part of the query planner's logic responsible for handling @include and @skip directives. Ensure that the conditional logic correctly determines whether a field should be included in the plan based on the variable's value.
   • Root field context: Verify that the planner correctly applies these directives to root fields (like productRecommender in your Query type). Sometimes, special handling might be needed for root fields compared to nested fields.

3. Variable Resolution: Confirm that the $included variable is being correctly passed into and resolved within the build_query_plan function. If the variable isn't being recognized or its value isn't propagated, the @include directive might not be evaluated as expected.

4. Expected Plan for Both Cases: Consider what the query_plan should look like when $included is true and when it's false. You might want to create two separate test cases (or modify this one to test both) to ensure the planner behaves correctly in both scenarios.

Debugging the query_plan object itself and stepping through the build_query_plan function, especially around directive processing, should give you a clearer picture of where the planning is going awry.

[ardatan]

@gemini-code-assist try to fix it

[gemini-code-assist]

@ardatan I understand you'd like me to fix it directly, but as an AI, I'm unable to make direct changes to the code or the pull request. My role is to provide guidance and suggestions.

The previous comment outlined several areas to investigate to diagnose and fix the "failing conditional root field planning." Have you had a chance to try any of those suggestions, particularly inspecting the query_plan object before the insta::assert_snapshot!? Sharing the output of that inspection would be a great next step, as it would give us more concrete information about what the planner is currently producing.