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

feat(apollo-engine-reportoing): sendVariableValues and sendHeaders. #2931

Merged
merged 12 commits into from
Jun 27, 2019
Merged

feat(apollo-engine-reportoing): sendVariableValues and sendHeaders. #2931

merged 12 commits into from
Jun 27, 2019

Commits on Jun 27, 2019

  1. - changed name of the new option (from enforcePrivateVariables to mas… 

    …kVariableValues), but this is still TBD

- use the same helper for both the deprecated privateVariable option and the new option, since the logic is (basically) the same
- added helper (and tests) to enforce that originalVariables.keys == modifiedVariables.keys
- updated documentation
    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    2c2d6c0 View commit details
    Browse the repository at this point in the history

  2. Changed new option to sendVariableValues instead of maskVariableValue… 

    …s, and the subsequent tests/docs
    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    e5c5432 View commit details
    Browse the repository at this point in the history

  3. adding new reporting option sendHeaders, fixing some names

    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    822bc0b View commit details
    Browse the repository at this point in the history

  4. addressing comments, name/argument changes, updating docs, adding and… 

    … fixing test cases
    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    b9d2b03 View commit details
    Browse the repository at this point in the history

  5. adding another parameter for specifying safelisted variable names

    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    dda89a8 View commit details
    Browse the repository at this point in the history

  6. more doc fixes, adding some checks for invalid inputs

    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    1eb61b1 View commit details
    Browse the repository at this point in the history

  7. changed suboption name, updating docs with more info on breaking change

    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    f49c714 View commit details
    Browse the repository at this point in the history

  8. Apply suggestions from code review: doc formatting, fixes (equality c… 

    …omparisons, constant declarations), more test cases

Co-Authored-By: Jesse Rosenberger <git@jro.cc>
    @abernix
    Helen and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    6fcd4d2 View commit details
    Browse the repository at this point in the history

  9. catching circular reference errors, adding test

    @abernix
    Helen Ho authored and abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    c3e4f9f View commit details
    Browse the repository at this point in the history

  10. Update CHANGELOG.md

    @abernix
    abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    8f9ca40 View commit details
    Browse the repository at this point in the history

  11. Use only the Node.js JSON cycles error. 

    Node.js only raises this particular error when cycles are detected.

While I first thought it was more defensive to catch the exact error we
anticipated, I'm slightly reconsidering whether this is defensive enough and
if we should, in fact, change this back to catching any error, particularly
since this runs async and might go undetected or cause a whole string of
a user's errors to not pass any variables.

Thoughts, @glasser?
    @abernix
    abernix committed Jun 27, 2019
    2 Configuration menu
    Copy the full SHA
    4b2f9d3 View commit details
    Browse the repository at this point in the history

  12. Rescind on my suggestion to precisely match the error. 

    I thought it made sense to catch only cycles, but I've changed my mind.  I
think there could be just arbitrary errors in a `toString` or `toJSON`
implementation which we'd still want to guard, particularly because these
errors are shipped async.

Ref: 4b2f9d3
Ref: #2931 (comment)
    @abernix
    abernix committed Jun 27, 2019
    Configuration menu
    Copy the full SHA
    6c9aa8f View commit details
    Browse the repository at this point in the history