Storing errors in the cache about apollo-feature-requests HOT 3 OPEN

Maybe storing errors is not the way to go, the abstraction of GraphQL errors is a bit messy. You could consider a different approach (not my article, but a worthy read)

from apollo-feature-requests.

I'm not sure that article is relevant, since it recommends a different approach for only some kinds of errors, not internal server errors for example. If you're suggesting that every individual field should be modeled as a union type and field resolvers can never throw exceptions, I don't think that's practical with GraphQL tooling as it exists today. It's just too cumbersome in most languages to handle union types on every field.

This feature request solves a specific problem with using cache-first fetch policy when the service returns an unexpected error, e.g. an internal server error. If the service returns partial data which is cached, then the first time you execute the query it will return the error, while later executions will return only the partial data and no error message, so the consuming component can no longer display the same information as it did the first time.

An example might be a page which shows user info. The first time you visit the page, it shows an error message about some missing data. If you leave the page and return, the data is still missing, but there is no error message. This is a confusing experience. From the perspective of the consuming component, the error is a part of the response, and to display the response correctly the component always needs both the error and the partial data.

On the other hand, I can understand why this is a hard problem to solve, because the cache operates at the level of fields while errors are modeled at the level of requests. For example, what should happen if a different query fetches some of the missing fields so the original query can return a more complete response -- should the original query still return the error which describes the reason for the originally missing fields? What if the response is eventually fully populated by other queries, does it still make sense to return the original error?

Ultimately it seems like this points to a fundamental misalignment between GraphQL semantics and the Apollo caching strategy, maybe even a problem with the GraphQL design itself. Maybe GraphQL should have treated every single field as an implicit union type, either an error or a value, so that errors are always represented within the structure of the data itself. Because that seems like the only way to make error handling consistent with the idea that every field can be fetched and cached independently.

from apollo-feature-requests.

@aquark Good point, and I wasn't suggesting that no error ever should be thrown, I was just suggesting an approach that helped me with handling of errors. But I just realized thanks to your reply that I probably completely missed the point of this feature request.

from apollo-feature-requests.