fix errors being triggered on successful requests

[Eluinhost]

The error id is a number not a string, stops errors being triggered incorrectly

[zyberspace]

I actually changed it to a string here: 25ad30f. Which version is right now? :o

[Eluinhost]

First time I've looked at the project but I think it has to do with this change later on which then parsed it as an number: e371174

[zyberspace]

but I think it has to do with this change later on which then parsed it as an number: e371174

Oh yeah, that looks totally right, so ty then :D
That's why micro-optimization is bad XD (36b99fb)

[timklge]

Unfortunately I can't test on my own atm. Thanks for the fix!

[hnrch02]

First of all, this was a breaking change introduced in a patch version (I'm assuming this project follows SemVer?) but secondly and more importantly how am I supposed to know now whether actions like "login" or "use" were successful when all three arguments supplied to the callback (error, response, rawResponse) are all undefined?

[zyberspace]

@hnrch02: Why is this a breaking change? It is only backend error parsing.
Also it is a fix, so patch version is completely fine.

[hnrch02]

Yes, it is a backend error parsing change which removes the { id: 0, msg: 'ok' } "error" object which I was using the identify whether login and use were successfully executed. It broke my application when updating to the latest version of this package thus being a breaking change.

Anyway, it makes more sense that error is undefined when there is actually no error so I'll just change my app to adapt to this change. I was just surprised by this which I again did not expect to see in a patch version.

[zyberspace]

OK, i am sry then for this, but this behaviour (undefined when no error) was always wanted this way.
So this is still just a bug-fix, but i get your point.

If i have time, i will maybe take a deeper look over the whole code and, additionally, create some tests. Those should prevent stuff like this then (in other words: yes, you are completely right! ;) ).