Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Normalize "operation_name" value inside supergraph request #5008

Draft
wants to merge 3 commits into
base: dev
Choose a base branch
from
Draft

Normalize "operation_name" value inside supergraph request #5008

wants to merge 3 commits into from
+38 −6

Conversation

IvanGoncharov
Copy link
Member

@IvanGoncharov IvanGoncharov commented Apr 23, 2024 •
edited

Currently, request.body.operation_name is a direct copy of operationName from the client request.
But this behavior is very confusing to customers who expect it to have an operation name, if any, extracted from the query.

Fixes #5014

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

  • Changes are compatible1
  • Documentation2 completed
  • Performance impact assessed and acceptable
  • Tests added and passing3
    • Unit Tests
    • Integration Tests
    • Manual Tests

Exceptions

Note any exceptions here

Notes

Footnotes

  1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩

  2. Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩

  3. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

@github-actions GitHub Actions

This comment has been minimized.

Sign in to view
@router-perf
Copy link

router-perf bot commented Apr 23, 2024

CI performance tests

  • step - Basic stress test that steps up the number of users over time
  • events_big_cap_high_rate_callback - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity using callback mode
  • large-request - Stress test with a 1 MB request payload
  • events - Stress test for events with a lot of users and deduplication ENABLED
  • xxlarge-request - Stress test with 100 MB request payload
  • events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
  • xlarge-request - Stress test with 10 MB request payload
  • step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
  • events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
  • no-graphos - Basic stress test, no GraphOS.
  • reload - Reload test over a long period of time at a constant rate of users
  • events_big_cap_high_rate - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity
  • events_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
  • const - Basic stress test that runs with a constant number of users

@IvanGoncharov IvanGoncharov marked this pull request as ready for review April 24, 2024 14:36
abernix
abernix requested changes Apr 24, 2024
View reviewed changes
Copy link
Member

@abernix abernix left a comment

Choose a reason for hiding this comment

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

I think it may be best if request.body.operation_name actually reflects what's passed in, I don't think we need to actually recommend people use that, but it's critical that the user have the ability to access it if they needed it. Let's take an exercise to think through that request.body.variables would be here, maybe? Do we want to change any of those things or keep them as opaque values? (Again the docs need to be clear about what you should use for a use case!)

But the thing that I think users are trying to accomplish is knowing what operation was executed. I'm not certain if that needs to be as rquest.body.operation_name. It could just be something else (you tell me — query.executed_operation_name or something?)

@abernix abernix marked this pull request as draft May 14, 2024 19:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@abernix abernix abernix requested changes

@bnjjj bnjjj bnjjj approved these changes

Requested changes must be addressed to merge this pull request.

Assignees

@IvanGoncharov IvanGoncharov

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

request.body.operaton_name is empty even query contain named operation
3 participants
@IvanGoncharov @abernix @bnjjj