Don't report ::p.error/attribute-unreachable for ::pcr/attribute-errors

[holyjak]

When I send the query [::pcr/attribute-errors] then I get back {::pcr/attribute-errors {{::p.error/cause ::p.error/attribute-unreachable}}}. A preferred behavior would be for Pathom to silently ignore this attribute appearing in the query.

You might wonder why do I include :pcr/attribute-errorr in my query when Pathom would return it anyway? That's because I use Fulcro and its logic is that no data that is not requested should make it to the client code. Or, as Tony puts it,

This is sort of a pedantic opinion on my part: the query processing should never return something you don’t ask for as part of the response. Throwing exceptions would be ok, but returning data that isn’t in the query is just “wrong”. The client should have to ask for the errors as data if they want them that way.

Of course I can add some plugin to omit this attribute from the AST but it would be nicer if I did not need to do that :)

Thank you for all the awesome work!

[wilkerlucio]

Problem Analysis

Description

Pathom considers an error when the user requests the attribute errors in a query, even though the attribute will be there in case of an error. This happens because the planner doesn't know anything about ::pcr/attribute-errors and when trying to plan, it finds no possible path for that attribute.

Problem

As described in the above report, a Fulcro client expects that if the data isn't in the request, it shouldn't reach the client. Since the data is, in fact, at the output, the processor must understand the request. Otherwise, they will have to rely on some confusing and error-prone code to remove the attribute from the query on the way out.

The Solution Space

https://docs.google.com/spreadsheets/d/1SUQxgKtqbi1DCULFcLrntQ-HNSegzDAM86hG95H24hQ/edit#gid=0