Global failure conditions for a whole resource

💬 Feature Requests
1

Hi folks,

The lack of reusability of failure conditions is a major pain point for us. I would like to see some way to set failure conditions or specify middleware on an entire Resource, instead of needing to individually set failure conditions or transformers on every single Query against the Resource.

A common pain point for GraphQL resources is that the endpoint always returns HTTP 200, so the client is unaware of errors when the query or mutation has failed.

The spec provides for a list of errors to be returned in the errors parameter. GraphQL

Retool does provide failure conditions as a way to return errors given any custom criteria. This does solve the problem for individual queries, but it is a tedious and error-prone way to tackle the problem. (And frankly it's surprising that this is necessary, given that the GraphQL spec defines that this is the way endpoints should operate. Retool's GraphQL client is not really operating to spec by ignoring errors.)

If we miss adding the failure condition for just a single query, it results in silent failures when the resource returns an error, which is difficult to troubleshoot and frustrating for users.

Ideally, we would be able to either:

A. Create failure conditions that apply to an entire resource, across all of its queries
B. Create custom javascript middleware that operates on the results of a resource

Either of these options would allow us to tell Retool to look for items in the errors list. This would also be useful for anyone creating user-facing error objects inside the GraphQL data, which is a recommended pattern.

Thanks!

2 Likes
2

A feature like that would be super helpful for my team as well! Right now, we're copy-pasting a transformer that deals with GraphQL errors into every single of our query calls and it's getting pretty messy, we've been getting quite some support requests from users that didn't get an error message from our retool app.

3

Thank you for this feedback! I posted this internally as well. I'll share any updates on this thread :blush:

4

This is strongly needed, the graphql spec encourages sending a 200 (with an errors array) thus is dangerous when crafting apps in Retool that have several queries/mutations since the default behaviour is to swallow the error.

5

We have exactly the same need wihtin my team. Any updates on this ?

6

Hi @emilecohen, welcome to the forum! :wave:
Unfortunately, there hasn't been any updates on this feature. I added your +1 internally and will post updates here when/if there are any.

1 Like
7

Thank you @Paulo for you answer.

As a way to bypass this issue I am trying to create a wrapper that I can reuse for all my GQL queries.

This wrapper would take as input: the GQL function, the functions' input, the list of errors. And it would handle error handling in Retool and retries.

But I am having trouble passing the GQL function as a parameter to my JS wrapper. Any simple way to do this?

Thanks

8

Could you share your existing settings? We can use additionalScope to pass data to any query.

Here is a simplified example:

9

Sorry, I am actually trying to pass a ressource (GQL mutation) as an input to a JS function.

Here is an example of what I am trying to do:

async function graphqlWrapper({ func, variables }) {
      // Dynamically trigger the GraphQL endpoint using the passed function
      const payload = await func.trigger({
        additionalScope: {
          input: variables.input
        }
      });
      console.log(payload)
}
10

From a JS perspective this looks good. What are we seeing when we invoke this function passing the GQL mutation?