execution: Preserve extensions in parseValue errors

[glasser]

Previously, the only fields observed on an error thrown by (for example)
parseValue were message and originalError. Now, the error itself is
used as the originalError; this may be mildly backwards-incompatible
if you added extensions on the error itself which you for some reason
wanted to disappear, but that seems unlikely.

Addresses an issue raised in
apollographql/apollo-server#7178

[netlify]

✅ Deploy Preview for compassionate-pike-271cb3 ready!

Name	Link
🔨 Latest commit	5a76837
🔍 Latest deploy log	https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/637ea52154daea0009201986
😎 Deploy Preview	https://deploy-preview-3785--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions]

Hi @glasser, I'm @github-actions bot happy to help you with this PR 👋

Supported commands

Please post this commands in separate comments and only one per comment:

• @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
• @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM

[glasser]

I'm not sure this is the best solution: another solution would just be to always pass originalError: error, and another would be to explicitly copy extensions: error.extensions along with originalError: error.originalError (and maybe other things like stack as well?). These both also cause my test to pass, and also ensure that extensions from error are honored even if it itself has its own originalError, so in fact originalError: error feels like the best approach. However, the approach taken in this PR feels a bit more backwards-compatible?

(Is there an appropriate pattern for "make a copy of an error but with the message changed"? Perhaps going through .toJSON()?)

[glasser]

As a workaround, you can throw something like:

const e = new GraphQLError('message', {extensions: {my: 'extensions'}});
throw new GraphQLError(e.message, { originalError: e });

[IvanGoncharov]

These both also cause my test to pass, and also ensure that extensions from error are honored even if it itself has its own originalError, so in fact originalError: error feels like the best approach.

@glasser I agree, having correct semantic "chain of errors" make more sense.
Original error for "variable error" is "value error", and original error for "value error".

The entire mechanism of prefixing errors is a workaround for absence of proper way to represent "error chaining" in graphql, see graphql/graphql-spec#893
Moreover, single "variable error" can contain multiple "value error"s and it useful for IDE validation.

TL;DR; I'm for originalError: error solution (as breaking change) in main and for originalError: error.originalError ?? error solution for v15/v16 if needed.

What do you think?

[glasser]

@IvanGoncharov OK, I changed this to originalError: error. I don't feel too much urgency for a backport (as long as v17 is coming out eventually!) since there's a workaround.