[Bug] Cannot read property 'total_count' of undefined

[rushilshah1]

[Bug] Cannot read property 'total_count' of undefined

[sergiop]

Thanks @rushilshah1 for the catch. I need to investigate why window.fetch() doesn't manage the 400 status as an error and possibly add a custom handler for this error to avoid everything blows up.
Give me some days, it shouldn't be too complex. 😉

[sergiop]

Hi @rushilshah1, sorry for my late reply.
total_count is the number of gifs returned by a query on Giphy's API. Here a piece of the JSON response returned by the Api:

"pagination": {
  "total_count": 12744,
  "count": 5,
  "offset": 0
},

That error means that pagination is undefined when the component tries to display some data. It's weird, I need to check why or put some boundaries to avoid the error in those situations.

Please, give me some time to try to fix it, I'm a little busy at the moment. ;-)

[sergiop]

I have said "weird" because the error happens exactly here, at lines 27 or 36.

https://github.com/sergiop/react-giphy-searchbox/blob/master/src/reducers/dataFetchReducer.js#L20-L37

This means that at the moment we call FETCH_SUCCESS or FETCH_MORE_SUCCESS actions, pagination is undefined. And this is really strange, because these actions are called here, after a successful response by the API, so at this point pagination has to be true by design:

https://github.com/sergiop/react-giphy-searchbox/blob/master/src/hooks/useApi.js#L19-L35

When the error happens, can you take a look at the Network panel of Chrome's Developer Tool to check if the Api call returns a 200 code and the response contains the pagination item? Your help will be really useful because I have never triggered the error.

[rushilshah1]

Thanks for looking into this @sergiop!

This error is pretty hard to reproduce, but has happened intermittently on a few occasions. I was able to reproduce it today:

When I drilled down into the api call I got this (apologies, I did not have my network tab open to record more details, but can try again and follow up):

Seems like this 400 response only returned an attribute called message, thus why the pagination object is null. This seems like an issue with the Giphy Api as a similar issue has been reported. I can look to follow up with them as well, but in the meantime would you be able to add some simple error handling to the react-giphy-searchbox to protect the component from weird api issues like this?

[rushilshah1]

Created an issue for the Giphy API team - Giphy/GiphyAPI#229

[sergiop]

@rushilshah1 version 1.5.1 has fixed the error (and I need to admit it was a really BIG error!!! 😉).

[rushilshah1]

Thank you @sergiop! 😄

[rushilshah1]

Hey @sergiop I actually still got the error. I was able to drill down some more and here is what I see.

There is no 400 error anymore, but I got a 200 response back from their API and it is simply missing the pagination field:

[sergiop]

It's weird because both the home page and the CodeSandbox Demo use the last version and everything seems fine.
https://codesandbox.io/s/react-giphy-searchbox-l8dxc?fontsize=14
https://sergiop.github.io/react-giphy-searchbox/

But... wait... how is it possible a 200 without the pagination? Have you searched for something that returned an empty response? I see in your image that it was called the search endpoint, this means that you searched something in the input field, is that it? Can you help me to understand?

I just tested on the demo I published on the library home page (the one I linked above), searching for sdhfladjfhsdkfjhadfkjashdfkjsahdfaskdjh string. It returned me an empty response, but the pagination is not missing.

[rushilshah1]

Yeah, I think this is a problem with the Giphy api...In my screenshot I searched "what" which has search results, thus my offset was up to 1860. This issue is pretty hard to reproduce but shows up for me when I have multiple users on my app using the tool. My hunch is the API intermittently returns a bad response, and in this case we can see the pagination field is missing all together.

It seems a little extra, but would we be able to add a check to ensure even with a 200 response, the data, meta, and pagination attributes are present, otherwise treating it as a bad response? An alternative I could explore is that I can try to wrap your component in a try/catch in my application itself.

[rushilshah1]

I was able to replicate it by having two browsers/tabs open with the searchbox. I searched the same word in both of them (ex. what). I then started scrolling through one of them and got the error again

[sergiop]

I was able to replicate it by having two browsers/tabs open with the searchbox. I searched the same word in both of them (ex. what). I then started scrolling through one of them and got the error again

Mmm... no. I can't replicate using the demo on the home page. I opened it in three Chrome tabs, searched for what string, scrolled... and everything is working.

[sergiop]

Can you provide me the complete endpoint (with the query string) that returns that malformed response?
You can find it in the header tab:

What do you receive if you paste that URL in the browser address bar?

[sergiop]

What are you telling me is really an edge case, and it's really weird that the API returns that malformed response. Anyway, it's not related to the original topic, and it seems an API bug.

[sergiop]

@rushilshah1 I just opened a PR but I'm not really sure because I never triggered this bug. Anyway... this shows a generic error (Oops! Something went wrong. Please, try again.) if the 200 response doesn't contain the pagination.

[rushilshah1]

@sergiop great, thank you so much! This really is an odd edge case - your partnership is much appreciated 😄

[sergiop]

@rushilshah1 only because I'm on vacation and I have nowhere to go in these pandemic days... 😄
Anyway... I just published v1.5.2, let me know if it fixes your issue.