fix(executor): ensure variables passed to subgraph requests

[rawkode]

• Forward collected operation variables to each subgraph fetch.
• Previously execute_fetch_node always built HttpExecutionRequest with variables: None, so any resolver that expected arguments saw them missing, threw Variable \… not provided, and the federated response ended up as invalid JSON ({"data":,"errors":[…]}).
• Build the borrowed HashMap<&str, &sonic_rs::Value> from the query plan’s variable_values before invoking the executor so subgraphs receive the inputs they need.

[gemini-code-assist]

Summary of Changes

Hello @rawkode, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical issue in the executor where subgraph requests were not correctly receiving operation variables. Previously, all subgraph fetches were initiated without variables, causing resolvers to fail and resulting in malformed federated responses. The change introduces proper forwarding of collected variables to each subgraph, ensuring that all necessary arguments are passed, thereby enabling correct execution of federated queries and maintaining the integrity of the JSON responses.

Highlights

• Variable Forwarding: Ensured that operation variables are correctly forwarded to each subgraph fetch request, resolving issues where subgraphs were not receiving necessary arguments.
• Resolver Argument Fix: Addressed a bug where resolvers expecting arguments would fail due to HttpExecutionRequest always being built with variables: None, leading to Variable ... not provided errors.
• Valid Federated Responses: Prevented federated responses from becoming invalid JSON by ensuring that subgraphs receive the inputs they need for successful execution.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[Copilot]

Pull Request Overview

This PR fixes a critical bug where GraphQL variables were not being passed to subgraph requests during federated query execution, causing resolvers to fail with missing variable errors.

• Forward collected operation variables to each subgraph fetch request
• Replace hardcoded None variables with properly mapped variable references
• Build borrowed HashMap from query plan's variable_values for subgraph consumption

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[gemini-code-assist]

Code Review

This pull request correctly fixes an issue where variables were not being passed to subgraph requests. The change introduces logic to build and forward the operation variables to each subgraph fetch. My review includes a suggestion to optimize the creation of these variables to avoid redundant work for query plans with multiple fetch nodes.

[Copilot]

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[rawkode]

@ardatan I've changed the select helper to return None when usages is None. This along side the correct application when usages has keys should be the behaviour we expect.

Sorry for the iterations, but I do hope this is correct now.

[ardatan]

Thanks for the PR! 🙏
The changes look good to me! After others approve, we can merge and release!

[dotansimha]

I rebased and solved conflicts, will merge as soon as CI clears. Thanks @rawkode !

[rawkode]

Thanks, y'all 👍🏻

[github-actions]

✅ k6-benchmark results

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

     █ setup

     checks.........................: 100.00% ✓ 237990      ✗ 0    
     data_received..................: 7.0 GB  232 MB/s
     data_sent......................: 93 MB   3.1 MB/s
     http_req_blocked...............: avg=3.48µs   min=661ns  med=1.74µs  max=22.69ms  p(90)=2.45µs  p(95)=2.84µs  
     http_req_connecting............: avg=683ns    min=0s     med=0s      max=2.18ms   p(90)=0s      p(95)=0s      
     http_req_duration..............: avg=18.44ms  min=1.92ms med=17.51ms max=121.58ms p(90)=25.51ms p(95)=28.71ms 
       { expected_response:true }...: avg=18.44ms  min=1.92ms med=17.51ms max=121.58ms p(90)=25.51ms p(95)=28.71ms 
     http_req_failed................: 0.00%   ✓ 0           ✗ 79350
     http_req_receiving.............: avg=133.09µs min=24.2µs med=39.28µs max=92.52ms  p(90)=90.87µs p(95)=385.29µs
     http_req_sending...............: avg=24.98µs  min=5.5µs  med=10.59µs max=24.82ms  p(90)=16.17µs p(95)=29.68µs 
     http_req_tls_handshaking.......: avg=0s       min=0s     med=0s      max=0s       p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=18.28ms  min=1.86ms med=17.38ms max=110.32ms p(90)=25.26ms p(95)=28.39ms 
     http_reqs......................: 79350   2639.851963/s
     iteration_duration.............: avg=18.9ms   min=4.68ms med=17.86ms max=246.88ms p(90)=25.97ms p(95)=29.19ms 
     iterations.....................: 79330   2639.186594/s
     vus............................: 50      min=50        max=50 
     vus_max........................: 50      min=50        max=50 

[dotansimha]

Will be available in 0.0.11 in a few minutes :) Thanks @rawkode !