refactor(error-handling): add context to PlanExecutionError

[kamilkisiela]

This commit adds context to the PlanExecutionError enum. It includes the subgraph name and the affected path in case of a projection or header propagation failure.

It also adds a ResultExt trait to map ProjectionError and HeaderRuleRuntimeError to PlanExecutionError.

I will improve names soon, it's a draft anyway, I just wanted to showcase how we could do errors, instead of manually creating GraphQL Error with code and stuff in extensions.

[github-actions]

✅ k6-benchmark results

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

     █ setup

     checks.........................: 100.00% ✓ 203385      ✗ 0    
     data_received..................: 5.9 GB  198 MB/s
     data_sent......................: 80 MB   2.6 MB/s
     http_req_blocked...............: avg=3.6µs    min=681ns   med=1.77µs  max=3.33ms   p(90)=2.63µs  p(95)=3.04µs  
     http_req_connecting............: avg=1µs      min=0s      med=0s      max=3.21ms   p(90)=0s      p(95)=0s      
     http_req_duration..............: avg=21.64ms  min=2.32ms  med=20.63ms max=221.37ms p(90)=29.55ms p(95)=32.76ms 
       { expected_response:true }...: avg=21.64ms  min=2.32ms  med=20.63ms max=221.37ms p(90)=29.55ms p(95)=32.76ms 
     http_req_failed................: 0.00%   ✓ 0           ✗ 67815
     http_req_receiving.............: avg=169.77µs min=25.61µs med=40.83µs max=179.94ms p(90)=93.33µs p(95)=422.68µs
     http_req_sending...............: avg=24.38µs  min=5.86µs  med=11.15µs max=18.78ms  p(90)=17.21µs p(95)=27.08µs 
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s      max=0s       p(90)=0s      p(95)=0s      
     http_req_waiting...............: avg=21.45ms  min=2.27ms  med=20.5ms  max=72.3ms   p(90)=29.27ms p(95)=32.46ms 
     http_reqs......................: 67815   2254.389313/s
     iteration_duration.............: avg=22.11ms  min=5.02ms  med=20.98ms max=273.12ms p(90)=29.99ms p(95)=33.22ms 
     iterations.....................: 67795   2253.724448/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-513 ghcr.io/graphql-hive/router:sha-2e4de3e

Docker metadata

{
"buildx.build.ref": "builder-c9405e6d-e6d6-42e9-b89d-544bc9eb83ad/builder-c9405e6d-e6d6-42e9-b89d-544bc9eb83ad0/r7khlt5t0q0z5qxo7dxrlfw77",
"containerimage.descriptor": {
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "digest": "sha256:dd5491a7e87dd95b2496250ffff48ccfcf5c4c364bf66a3fb632cfafea969f4c",
  "size": 1609
},
"containerimage.digest": "sha256:dd5491a7e87dd95b2496250ffff48ccfcf5c4c364bf66a3fb632cfafea969f4c",
"image.name": "ghcr.io/graphql-hive/router:pr-513,ghcr.io/graphql-hive/router:sha-2e4de3e"
}

[kamilkisiela]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a more structured and performant approach to handling execution errors by adding context, such as subgraph name and path, in a lazy manner. This is a significant improvement over manual GraphQL error creation, as it avoids unnecessary work on successful execution paths. My review includes a couple of suggestions to further enhance the implementation: one for performance by avoiding an unnecessary clone during error conversion, and another to remove what appears to be dead code, improving maintainability. Overall, this is a solid contribution to improving the error handling mechanism.

[dotansimha]

I like strum usage here, it makes error code much simpler to deal with.

[dotansimha]

LGTM.

Can you elaborate on the need for lazy init of the error-context fields? Is it to evaluate/clone the value only in case there's an actual error?

I will improve names soon, it's a draft anyway, I just wanted to showcase how we could do errors, instead of manually creating GraphQL Error with code and stuff in extensions.

^ is it still a draft? I did not merge it due to this note 😆

[kamilkisiela]

Can you elaborate on the need for lazy init of the error-context fields? Is it to evaluate/clone the value only in case there's an actual error?

yes