Giter Site home page Giter Site logo

Comments (21)

youurayy avatar youurayy commented on March 29, 2024 21

Just got burned on this. Instead of correctly rejecting the promise on invalid (truncated) JSON, it simply returns the orignal string object. Bad bad bad. At least put a warning in the docs about this.

from axios.

youurayy avatar youurayy commented on March 29, 2024 15

@emilyemorehouse is this something you could fix, for the sake of all humanity?

from axios.

rubennorte avatar rubennorte commented on March 29, 2024 12

I think we should just reject with the parse errors. That'd make axios more predictable and easier to debug.

from axios.

vinnymac avatar vinnymac commented on March 29, 2024 8

Not sure how others are avoiding this issue after almost 3 years, but I decided to try to work around it for one of my projects. I would like to see how other people have been doing this as well.

I took notes from here and only raise an error for 2xx response codes.

If people find it useful I can make a PR of my commit. If you need this to raise for other response codes, just remove lines 67 and 71 in defaults.js

Another option for those who don’t want to fork is to just override transformResponse, and detect when data is a string, and parse on your own. Unfortunately this means you’ll do more work, and you can’t check the status code if you do that, but at least you have options.

from axios.

batiste avatar batiste commented on March 29, 2024 5

I also spent 1 hour today tryng to understand what is happening with some invalid JSON. Just reject the Promise, or at least console.log something...?

from axios.

youurayy avatar youurayy commented on March 29, 2024 5

imagine first finding out in production - not sure where the logical thinking has gone on this one

from axios.

jamesseanwright avatar jamesseanwright commented on March 29, 2024 4

Personally, I think Promise rejection is a good solution. At the very least, one could invoke console.error in the catch block to make developers aware of what has happened.

from axios.

pcone avatar pcone commented on March 29, 2024 3

I see this has been closed already, but imo neither of the available behaviours from silentJSONParsing are quite perfect for all use cases.
With silentJSONParsing on you can access the status code of the response, but the JSON parsing error is swallowed which isn't ideal.
But with silentJSONParsing off there's no longer any way to see what the status code of the response was, unless I'm missing something.

Effectively it seems like I have to choose between being able to know the status code or the JSON parsing error, but not both.

from axios.

ethanentW avatar ethanentW commented on March 29, 2024 2

This is among the most disappointing responses to a glaring issue I've seen in an open-source project. This has been an issue for almost 4 years... This is the reason I use my own HTTP package.

from axios.

jasonsaayman avatar jasonsaayman commented on March 29, 2024 2

Fixed in #3688

from axios.

demetriusnunes avatar demetriusnunes commented on March 29, 2024 1

I also think there should be an easy option to retry the request in these cases as it often boils down to a truncated response.

from axios.

soundstep avatar soundstep commented on March 29, 2024 1

+1 here, swallowing errors is never good

from axios.

rognstad avatar rognstad commented on March 29, 2024 1

I just got bitten by this in production today. The current behavior is really unintuitive and wasted a bunch of my time in debugging. Throwing an error would have pointed me in the right direction immediately and would have been helpfully caught/grouped in our error reporting. Even once I found that there was a disconnect between the type of data I got in the response vs. what the header said it should be, it wasn't trivial to find this issue as the explanation.

from axios.

thame avatar thame commented on March 29, 2024

I also encountered a scenario where this behavior is problematic. If the network connection is interrupted partially through the request, axios would not call an error and my application received malformed JSON which obviously led to lots of errors.

I too think that JSON parse errors should be caught and reported. I wasn't keen on forking or modifying the source files so my solution was to transform the response like this:

axios.get(URL, {
  transformResponse: [(response) => (JSON.parse(response))], 
})

from axios.

jmkenz avatar jmkenz commented on March 29, 2024

My approach to handling this is to wrap all axios requests in a promise, and reject that promise if the response from axios show a response.headers['content-type'] of 'application/json' and a response.data that is a string. From this I infer there was a JSON parsing error.

return new Promise((resolve, reject) => {
  axios.request(options)
    .then(response => {
      if (response.headers && response.headers['content-type'] && response.headers['content-type'].indexOf('application/json') >= 0 && _.isString(response.data)) {
        reject(new Error('Error parsing response data as JSON object'));
      } else {
        resolve(response);
      }
  });
});

from axios.

wujunze avatar wujunze commented on March 29, 2024

Should throw exception

from axios.

todorone avatar todorone commented on March 29, 2024

@vinnymac Can You please submit PR of Your solution?

from axios.

smakinson avatar smakinson commented on March 29, 2024

Just came across this as well, it seems if I manually add: responseType: 'json' (even though it's the default according to the docs) it at least keeps it form providing the bad data to the result.

from axios.

yarcl avatar yarcl commented on March 29, 2024

Is this responseText a problem? like "24\r\n{"success":"true", "payload":"123456"}\r\n0\r\n\r\n", and sometimes it returns "24\r\n{"success":"true", "payload":"123456"}\r\n". Is there anyone who can help, thanks a lot.

from axios.

ouzkhanmete avatar ouzkhanmete commented on March 29, 2024

imagine first finding out in production - not sure where the logical thinking has gone on this one

Generally speaking, that was exactly what we faced....

from axios.

porlov avatar porlov commented on March 29, 2024

Guys, any updates on this issue?
This is really confusing behavior that I've faced with recently.

from axios.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.