Skip to content

Conversation

@dotansimha
Copy link
Member

@dotansimha dotansimha commented Oct 28, 2025

We've seen that ClientRequestDetails is already used in multiple places, and the current implementation tries to avoid re-creating it by doing lazy init only when it's really used - which might still lead to multiple creation.
The original reason behind it was an issue with the lifetime definition of ClientRequestDetails.

Since ClientRequestDetails is constructed with data from multiple places, it needs to declare multiple lifetimes, based on where the data actually came from. This is the new definition:

/// The `ClientRequestDetails` itself + `OperationDetails` that's inside are both defined inside `execute_pipeline`. So both has `'exec` lifetime. 
/// The rest of the parameters are based on the `'req` lifetimes because the originated in the `ntex::Request`. 
pub struct ClientRequestDetails<'exec, 'req> {
    pub method: &'req Method,
    pub url: &'req http::Uri,
    pub headers: &'req NtexHeaderMap,
    pub operation: OperationDetails<'exec>,
}

In addition, this PR removed the need to clone the query and put it into a Cow in order to pass it around during execution. To do that, I changed the way ExecutionRequest is passed around - coerce_variables no longer takes ownership, and the way we have variables (and no variables) is also improved now.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @dotansimha, I'm Gemini Code Assist1! 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 introduces a significant refactoring to how ClientRequestDetails are handled within the router and executor components. The primary goal is to optimize performance and enhance correctness by ensuring that request details are constructed only once and then passed by reference throughout the request processing pipeline. This change addresses previous issues with redundant object creation and improves lifetime management, leading to a more efficient and robust system for handling client request information.

Highlights

  • Refactored ClientRequestDetails: The ClientRequestDetails struct is now defined once at the start of the request pipeline and passed by reference, eliminating redundant cloning and ensuring consistent usage across the application.
  • Improved Lifetime Management: The ClientRequestDetails struct has been updated with two lifetime parameters, 'exec and 'req, to accurately reflect the origin and lifetime of its constituent data, enhancing memory safety and correctness.
  • Function Signature Updates: Numerous functions and struct definitions across executor and router crates have been updated to accept ClientRequestDetails by reference and incorporate the new lifetime parameters, including execute_plan, request_override_context, evaluate, execute_query_plan, and various Executor and SubgraphExecutorMap methods.
  • Dependency Cleanup: Unnecessary imports like std::borrow::Cow and OperationKind have been removed from bin/router/src/pipeline/execution.rs as they are no longer required with the refactored ClientRequestDetails handling.
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.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request is a great refactoring that defines ClientRequestDetails once per request and passes it by reference, successfully avoiding many clones in the request pipeline. This improves performance and code clarity.

My review focuses on fully achieving the goal of "avoiding all clones". I've identified a couple of remaining heap allocations for the operation's name and query and provided a suggestion to eliminate them by adjusting the OperationDetails struct to use references. This change would make the request processing even more efficient, in line with the repository's performance-first style guide.

@github-actions
Copy link

github-actions bot commented Oct 28, 2025

k6-benchmark results

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

     █ setup

     checks.........................: 100.00% ✓ 217872      ✗ 0    
     data_received..................: 6.4 GB  212 MB/s
     data_sent......................: 85 MB   2.8 MB/s
     http_req_blocked...............: avg=3.11µs   min=691ns   med=1.68µs  max=15.91ms  p(90)=2.32µs  p(95)=2.67µs  
     http_req_connecting............: avg=487ns    min=0s      med=0s      max=1.58ms   p(90)=0s      p(95)=0s      
     http_req_duration..............: avg=20.16ms  min=2.14ms  med=19.15ms max=106.35ms p(90)=27.75ms p(95)=31.04ms 
       { expected_response:true }...: avg=20.16ms  min=2.14ms  med=19.15ms max=106.35ms p(90)=27.75ms p(95)=31.04ms 
     http_req_failed................: 0.00%   ✓ 0           ✗ 72644
     http_req_receiving.............: avg=133.39µs min=25.46µs med=38.46µs max=87.62ms  p(90)=80.96µs p(95)=379.66µs
     http_req_sending...............: avg=21.31µs  min=5.27µs  med=10.56µs max=23.29ms  p(90)=15.18µs p(95)=25.85µs 
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s      max=0s       p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=20.01ms  min=2.07ms  med=19.04ms max=87.24ms  p(90)=27.52ms p(95)=30.73ms 
     http_reqs......................: 72644   2416.449244/s
     iteration_duration.............: avg=20.64ms  min=6.1ms   med=19.52ms max=237.39ms p(90)=28.21ms p(95)=31.52ms 
     iterations.....................: 72624   2415.783958/s
     vus............................: 50      min=50        max=50 
     vus_max........................: 50      min=50        max=50 

@github-actions
Copy link

github-actions bot commented Oct 28, 2025

🐋 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-532 ghcr.io/graphql-hive/router:sha-410114f

Docker metadata
{
"buildx.build.ref": "builder-416cd0cb-880f-4099-b9e4-a1a092b42a2b/builder-416cd0cb-880f-4099-b9e4-a1a092b42a2b0/axmz96fj2ea97kjx4qxdw7lo6",
"containerimage.descriptor": {
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "digest": "sha256:b1f09b70b597cdccc96fbc1e3e1256cd2394fbbd89f1e181856b9b0020b497c9",
  "size": 1609
},
"containerimage.digest": "sha256:b1f09b70b597cdccc96fbc1e3e1256cd2394fbbd89f1e181856b9b0020b497c9",
"image.name": "ghcr.io/graphql-hive/router:pr-532,ghcr.io/graphql-hive/router:sha-410114f"
}

@dotansimha dotansimha force-pushed the optimize-ClientRequestDetails branch 4 times, most recently from 95b6aa4 to bf644fa Compare October 28, 2025 09:57
@dotansimha dotansimha changed the title refactor(executor, router): define ClientRequestDetails only once and avoid all clones refactor(executor, router): define ClientRequestDetails only once and avoid all clones, improve how coerce_variables is done Oct 28, 2025
@dotansimha dotansimha force-pushed the optimize-ClientRequestDetails branch from bf644fa to fbd475f Compare October 28, 2025 10:03
@dotansimha dotansimha merged commit 6179f66 into main Oct 28, 2025
18 checks passed
@dotansimha dotansimha deleted the optimize-ClientRequestDetails branch October 28, 2025 10:13
@theguild-bot theguild-bot mentioned this pull request Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants