REST API Error Handling

Queries and Resources
21

Hi @yogi - when I put {{ error }} as you suggested, it's pulling the error response body - see screenshot below!

Screen Shot 2020-11-30 at 3.27.48 PM
Screen Shot 2020-11-30 at 3.27.48 PM1324×262 34 KB

22

It looks like data.error has the full http response body mapped to it…

23

@gilcrest Does using {{ error }} and {{ data.error.message }} work for your use case then?

Perhaps you’d have to do {{ JSON.parse(error.error.message) }} (not sure about the exact code here, it’d be some permutation of this).

24

Hi @yogi - I just tested and it seems I can use the below as a workaround. Ideally, I think it makes more sense to be able to access the statusCode and key off that, but this will work in my use case as my API error response body is always the same structure. Are you planning to allow access to the statusCode? Eventually, every one of my queries will be rekeyed to this logic, so I'm wondering if that will eventually work. The nice thing about the statusCode is that it's a good clean boolean to key off of - either the status code is 400, etc. or it's not (e.g. 200). In the case of having to key off the error message itself, in the cases where the query is successful, the condition shows a problem because data.error is undefined. It still works, because it's not truthy, but the statusCode is more rock solid. Know what I mean?

Screen Shot 2020-11-30 at 4.22.51 PM
Screen Shot 2020-11-30 at 4.22.51 PM1364×192 14.5 KB

Thanks again!

Dan

25

The other thing to consider is that your placeholder text for Failure conditions actually references data.statusCode === 400 (see below):

Screen Shot 2020-11-30 at 4.57.02 PM
Screen Shot 2020-11-30 at 4.57.02 PM1884×272 32.2 KB

If you're not going to support this, you should update this as it's confusing...

Thanks!

Dan

26

@gilcrest we’ll soon be pushing out fixes to this! The copy will change a little bit and you’ll be able to access the status code inside the metadata object

1 Like
27

Great - thanks, let me know whenever - I’ll give it another test!

28

You should be able to test out using metadata now!

1 Like
29

Related to this, how do I treat a 404 error as a success and still run the transformer?

Even though I’ve specified my failure condition ({{ metadata.status !== 404 && metadata.status !== 200}}) and it isn’t fulfilled, I still get a warning during development and the transformer isn’t run.

30

@yogi - works great!!! Thank you so much for all your help! :+1:

1 Like
31

@bfelbo Hi and thanks for writing in!

Could we learn a bit more about your usecase? Specifically I’m curious about:

  1. generally what your request is returning
  2. what you have in your transformer
  3. why and when you’d want to mark this failure as a success
  4. do expect this query to fail and get marked as success all the time or just some of the time?

Currently this feature doesn’t support turning failures into successes but lets see if we can get you a work around or if we can implement this somehow

32

Thanks @yogi. We’re doing a lookup for whether someone is in our Front email contact book. It’s completely fine if they’re not - we just need to know if that’s the case.

Our transformer is simple: return { id: data.id, name: data.name }. We’d like these to just be undefined in the event of a 404 error. The main issue is that it adds more complexity in other components / queries to do an if/else based on whether’s there an error. Moreover, it’s confusing for other devs to see these (unexpected, but normal) errors popping up while developing.

We’ll survive for now, but would be awesome to have in the future :slight_smile: Thanks for building a super useful product!