Skip to content

Avoid clones in impl From<PlanExecutionError> for GraphQLError#666

Merged
ardatan merged 2 commits intographql_errorfrom
kamil-graphql_error
Jan 13, 2026
Merged

Avoid clones in impl From<PlanExecutionError> for GraphQLError#666
ardatan merged 2 commits intographql_errorfrom
kamil-graphql_error

Conversation

@kamilkisiela
Copy link
Contributor

@kamilkisiela kamilkisiela commented Jan 13, 2026

Before

impl From<PlanExecutionError> for GraphQLError {
    fn from(val: PlanExecutionError) -> Self {
        let mut error = GraphQLError::from_message_and_code(val.to_string(), val.error_code());
        
        if let Some(subgraph_name) = val.subgraph_name() {   // Returns &Option<String>
            error = error.add_subgraph_name(subgraph_name);  // Clones via Into<String>
        }
        
        if let Some(affected_path) = val.affected_path() {   // Returns &Option<String>
            error = error.add_affected_path(affected_path);  // Clones via Into<String>
        }
        error
    }
}

What happens:

  1. val.subgraph_name() returns &Option<String>
  2. add_subgraph_name<TStr: Into<String>>() expects an Into<String>
  3. When Rust sees &String -> Into<String>, it uses the impl that clones the String
  4. Same issue for affected_path

We end up with 2 unnecessary heap allocations per error conversion.

After

I moved owned values out of the structure, to the add_subgraph_name and add_affected_path methods.
When Rust sees Stirng -> Into<String>, it will just use the owned String, so no clones.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @kamilkisiela, 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 targeted optimization to the error handling mechanism, specifically focusing on the conversion from PlanExecutionError to GraphQLError. By adjusting field visibility and refactoring the conversion logic, it significantly reduces memory allocations and improves efficiency during error processing, without altering the external behavior or structure of the error types.

Highlights

  • Performance Optimization: Eliminated two unnecessary heap allocations per error conversion by avoiding string cloning when transforming PlanExecutionError into GraphQLError.
  • Visibility Change: Made the subgraph_name and affected_path fields within the PlanExecutionErrorContext struct public to enable direct destructuring and ownership transfer.
  • Error Conversion Logic: Modified the From<PlanExecutionError> for GraphQLError implementation to directly move owned Option<String> values from the error context into the GraphQLError builder methods, rather than cloning references.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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 effectively addresses a performance issue by eliminating unnecessary string cloning during error conversion, which aligns well with the repository's focus on performance. The approach of making struct fields public to enable moving values is a valid solution. However, I've provided a couple of suggestions for an alternative implementation that achieves the same performance benefits while preserving encapsulation. By using destructuring within the From implementation, we can avoid modifying the public API of PlanExecutionErrorContext, leading to a more robust and maintainable design.

@kamilkisiela kamilkisiela changed the title Expose error context fields and avoid clones Avoid clones in impl From<PlanExecutionError> for GraphQLError Jan 13, 2026
@github-actions
Copy link

k6-benchmark results

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

     █ setup

     checks.........................: 100.00% ✓ 222138      ✗ 0    
     data_received..................: 6.5 GB  215 MB/s
     data_sent......................: 87 MB   2.9 MB/s
     http_req_blocked...............: avg=2.71µs   min=721ns   med=1.79µs  max=3.03ms   p(90)=2.47µs  p(95)=2.79µs  
     http_req_connecting............: avg=138ns    min=0s      med=0s      max=710.66µs p(90)=0s      p(95)=0s      
     http_req_duration..............: avg=19.76ms  min=2.25ms  med=18.85ms max=178.59ms p(90)=27.02ms p(95)=29.93ms 
       { expected_response:true }...: avg=19.76ms  min=2.25ms  med=18.85ms max=178.59ms p(90)=27.02ms p(95)=29.93ms 
     http_req_failed................: 0.00%   ✓ 0           ✗ 74066
     http_req_receiving.............: avg=167.47µs min=25.18µs med=39.25µs max=139.69ms p(90)=83.78µs p(95)=380.47µs
     http_req_sending...............: avg=22.81µs  min=5.29µs  med=10.59µs max=17.99ms  p(90)=15.23µs p(95)=26.79µs 
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s      max=0s       p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=19.57ms  min=2.2ms   med=18.72ms max=66.28ms  p(90)=26.76ms p(95)=29.67ms 
     http_reqs......................: 74066   2463.008473/s
     iteration_duration.............: avg=20.25ms  min=5.41ms  med=19.2ms  max=329.63ms p(90)=27.45ms p(95)=30.41ms 
     iterations.....................: 74046   2462.343388/s
     vus............................: 50      min=50        max=50 
     vus_max........................: 50      min=50        max=50 

@github-actions
Copy link

🐋 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-666 ghcr.io/graphql-hive/router:sha-6c4e1e7

Docker metadata
{
"buildx.build.ref": "builder-5f5594e8-a468-49b4-8499-3617dd79c881/builder-5f5594e8-a468-49b4-8499-3617dd79c8810/ekhdd4fp3anuo22mvps5tc4lq",
"containerimage.descriptor": {
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "digest": "sha256:e8c70900041204ec7f32fe31c4c82b1f53315f15e848938465afb2b7ab0b2edd",
  "size": 1609
},
"containerimage.digest": "sha256:e8c70900041204ec7f32fe31c4c82b1f53315f15e848938465afb2b7ab0b2edd",
"image.name": "ghcr.io/graphql-hive/router:pr-666,ghcr.io/graphql-hive/router:sha-6c4e1e7"
}

@kamilkisiela kamilkisiela requested a review from ardatan January 13, 2026 10:04
@ardatan ardatan merged commit 306cff0 into graphql_error Jan 13, 2026
21 of 22 checks passed
@ardatan ardatan deleted the kamil-graphql_error branch January 13, 2026 11:22
ardatan pushed a commit that referenced this pull request Jan 13, 2026
**Before**

```rust
impl From<PlanExecutionError> for GraphQLError {
    fn from(val: PlanExecutionError) -> Self {
        let mut error = GraphQLError::from_message_and_code(val.to_string(), val.error_code());
        
        if let Some(subgraph_name) = val.subgraph_name() {   // Returns &Option<String>
            error = error.add_subgraph_name(subgraph_name);  // Clones via Into<String>
        }
        
        if let Some(affected_path) = val.affected_path() {   // Returns &Option<String>
            error = error.add_affected_path(affected_path);  // Clones via Into<String>
        }
        error
    }
}
```

What happens:
1. `val.subgraph_name()` returns `&Option<String>`
2. `add_subgraph_name<TStr: Into<String>>()` expects an `Into<String>`
3. When Rust sees `&String` -> `Into<String>`, it uses the impl that
clones the String
4. Same issue for `affected_path`

We end up with 2 unnecessary heap allocations per error conversion.

**After**

I moved owned values out of the structure, to the `add_subgraph_name`
and `add_affected_path` methods.
When Rust sees `Stirng` -> `Into<String>`, it will just use the owned
String, so no clones.
ardatan pushed a commit that referenced this pull request Jan 13, 2026
**Before**

```rust
impl From<PlanExecutionError> for GraphQLError {
    fn from(val: PlanExecutionError) -> Self {
        let mut error = GraphQLError::from_message_and_code(val.to_string(), val.error_code());
        
        if let Some(subgraph_name) = val.subgraph_name() {   // Returns &Option<String>
            error = error.add_subgraph_name(subgraph_name);  // Clones via Into<String>
        }
        
        if let Some(affected_path) = val.affected_path() {   // Returns &Option<String>
            error = error.add_affected_path(affected_path);  // Clones via Into<String>
        }
        error
    }
}
```

What happens:
1. `val.subgraph_name()` returns `&Option<String>`
2. `add_subgraph_name<TStr: Into<String>>()` expects an `Into<String>`
3. When Rust sees `&String` -> `Into<String>`, it uses the impl that
clones the String
4. Same issue for `affected_path`

We end up with 2 unnecessary heap allocations per error conversion.

**After**

I moved owned values out of the structure, to the `add_subgraph_name`
and `add_affected_path` methods.
When Rust sees `Stirng` -> `Into<String>`, it will just use the owned
String, so no clones.
kamilkisiela added a commit that referenced this pull request Jan 14, 2026
**Before**

```rust
impl From<PlanExecutionError> for GraphQLError {
    fn from(val: PlanExecutionError) -> Self {
        let mut error = GraphQLError::from_message_and_code(val.to_string(), val.error_code());
        
        if let Some(subgraph_name) = val.subgraph_name() {   // Returns &Option<String>
            error = error.add_subgraph_name(subgraph_name);  // Clones via Into<String>
        }
        
        if let Some(affected_path) = val.affected_path() {   // Returns &Option<String>
            error = error.add_affected_path(affected_path);  // Clones via Into<String>
        }
        error
    }
}
```

What happens:
1. `val.subgraph_name()` returns `&Option<String>`
2. `add_subgraph_name<TStr: Into<String>>()` expects an `Into<String>`
3. When Rust sees `&String` -> `Into<String>`, it uses the impl that
clones the String
4. Same issue for `affected_path`

We end up with 2 unnecessary heap allocations per error conversion.

**After**

I moved owned values out of the structure, to the `add_subgraph_name`
and `add_affected_path` methods.
When Rust sees `Stirng` -> `Into<String>`, it will just use the owned
String, so no clones.
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.

2 participants