Silent failure when parsing a resonse.body from a 404

[bbarker]

Describe the bug

Originally mentioned in #26 (comment)

I never was able to figure this out, and ran out of time on the issue for now. It seems like response.body was defined, and looked like this: "{\"errors\":[{\"status\":\"404\",\"title\":\"The resource you are looking for doesn't exist.\"}]}". As I was asking affjax for a string type (and indeed confirmed that this was a string in JavaScript), then parsing it manually. I confirmed that my JSON parser can gracefully fail on that particular string as well, as part of a unit test.

The really interesting this is that in purescript, if I do something like:

log $ response.body
log $ response.statusText

The first log will succeed, but execution in that codepath seems to stop after that. The second message is never logged. If I reverse the order of the log statements, the same occurs: the first one logs, the second one does not.

No other errors show up in the web console other than the XHR 404, making it a bit of a mystery there as well.

To Reproduce

Tested with affjax 10.0.0

I haven't yet come up with a self-contained example, but will update here when I do. What is the best way to make some nested widgets in try.purescript.org?

Briefly, my original code looks something like this:

      resEi <- liftAff $ try $ AJ.get AJ.string $ urlToString jsonUrl
      -- ... snip ...
      let res = join $ lmap AJ.XHRError resEi
      in case res of
        Left err -> errorBox $ EX.error $
          "GET /api response failed to decode: " <> AJ.printError err
        Right response -> pure $ Tuple doi (Just $ readRecordJSON response.body)

Adding the log statements after the Right response -> is where things get interesting.

Expected behavior
No silent failures - if a failure occurs, an exception should be thrown, or ideally a left value should be generated if possible.

[garyb]

Definitely going to need an exact reproduction case for this one! It seems "impossible" that it would stop after the first log.

The library has also definitely been used to handle many varied status-code responses for errors and successes.

Probably the easiest way to set up a reproduction is just put it in a small repo - have an express server with an endpoint that serves that error, or something like that, and then the affjax thing running from main for the PS part.