[bug] formatError is called with a different error and not the original error

[iambumblehead]

Package Versions:

[email protected] [email protected] [email protected]

Expected Behavior:

Defining the custom formatError function should not trigger unexpected or unusual side-effects outside itself and it should be called with the original error instance.

Actual Behavior:

When formatError is defined, it is called with a different error and not the original error. Defining formatError as an empty function expression results in a different final error response from the server. An unpredictable response lifecycle is triggered if formatError exists.

Reproduction:

• throw an error that includes an additional property, errInstance.error_code = 12345;
• (good) the service response includes exception.error_code: 12345;
• stop the service and define an empty apollo formatError function, formatError (err) { return err; }
• start the service and, again, throw the error which includes the additional property
• (not good) the service response does not include exception.error_code: 12345; and also the response includes additional details not found in the previous error, such as "locations": [{"line": 2,"column": 3}],

Possibly Related

https://github.com/apollographql/apollo-server/issues/4734

[glasser]

There is a lot about Apollo Server error handling that is counterintuitive. Cleaning this up is on the roadmap for Apollo Server 4. cc @IvanGoncharov

[trevor-scheer]

formatError now receives the original error as the second argument in AS v4.

The existence of formatError should no longer trigger any unexpected side-effects, but if that's still the case please open another issue (and a reproduction would be handy!)

...formatError is now always called, either with a default no-op or the user-provided function: https://github.com/apollographql/apollo-server/blob/a404bf17e86d6f53588b2796c9190ad98779a6f9/packages/server/src/errorNormalize.ts#L34

[iambumblehead]

my late thank you for the responses here