I think this is intentional. The idea is not to expose any detail about an unexpected error. You can configure error masking on your own if you want to expose path.

I think this is intentional. The idea is not to expose any detail about an unexpected error. You can configure error masking on your own if you want to expose path.

but the path is not really confidential detail.
I think consumer should know where the error occured - because otherwise it cannot know whether data is missing because of error, or because its just not existing.

It should be preserved if it is a GraphqlError, which will have a path. Otherwise, if it is an exception, you probably don't want to give any information about which resolver thrown this error on consumer side by default.

You can either have some instrumentation server side to log/store the unexpected exception, or you should add a mechanism to allow your customer, under strict and restricted circumstances, get access to the unmasked errors (like in a sandbox environment, a special role, or any kind of allow list like this)

The idea is not to give consumer unmasked error, but to know that there is SOME error ar certain path. Basically to know that data is missing, because of error, not just because.

I understand your use case, but for this, you should either manually handle errors and throw a GraphqlError or customise the formatError function.

Providing the path for an unknown internal error is actually giving precious informations to a potential attack. It can be used to know exactly which field is leading to error and use this information to investigate further for potential security breach.

It can be seen as a bit strict, but we want to provide good default security configuration. This way, we enforce that the user explicitly understand that this kind information will be available to consumers.

Perhaps we can have better documentation on this point ? Like providing some examples on how to loosen the default behaviour ?