Nokogiri::XML::XPath::SyntaxError: Undefined namespace prefix: //xmlns:FaultInfo/xmlns:Message about quickeebooks

[ruckus]

I have seen this intermittently myself (I last saw it a couple of days ago). My feeling is that its related to Intuit which is why I haven't dug into it because it will work fine a few minutes later.

Deep in the HTML message below I do see this line:

"The request sent by the client was syntactically incorrect (message=No destination found for given partition key; errorCode=007001; statusCode=400"

Not sure what means but sounds like an internal Intuit failure?

On Mar 18, 2013, at 9:05 AM, Matt Rogish [email protected] wrote:

It appears the QuickBooks Online API is returning unexpected fault error for some of our users.

Nokogiri::XML::XPath::SyntaxError: Undefined namespace prefix: //xmlns:FaultInfo/xmlns:Message
from /app/vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/lib/nokogiri/xml/node.rb:159:in evaluate' from /app/vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/lib/nokogiri/xml/node.rb:159:inblock in xpath'
from /app/vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/lib/nokogiri/xml/node.rb:150:in map' from /app/vendor/bundle/ruby/1.9.1/gems/nokogiri-1.5.6/lib/nokogiri/xml/node.rb:150:inxpath'
from /app/vendor/bundle/ruby/1.9.1/bundler/gems/quickeebooks-98d817de7f5a/lib/quickeebooks/online/service/service_base.rb:177:in parse_intuit_error' from /app/vendor/bundle/ruby/1.9.1/bundler/gems/quickeebooks-98d817de7f5a/lib/quickeebooks/online/service/service_base.rb:164:incheck_response'
from /app/vendor/bundle/ruby/1.9.1/bundler/gems/quickeebooks-98d817de7f5a/lib/quickeebooks/online/service/service_base.rb:142:in do_http' from /app/vendor/bundle/ruby/1.9.1/bundler/gems/quickeebooks-98d817de7f5a/lib/quickeebooks/online/service/service_base.rb:129:indo_http_get'
from /app/vendor/bundle/ruby/1.9.1/bundler/gems/quickeebooks-98d817de7f5a/lib/quickeebooks/online/service/company_meta_data.rb:13:in `load'
The response, instead of being XML as specified in the docs (https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online/0300_Error_Handling/0050_HTTP_Status_Codes), is a HTML page:

<title>JBoss Web/2.1.12.GA-patch-03 - Error report</title><style></style>

HTTP Status 400 - message=No destination found for given partition key; errorCode=007001; statusCode=400

---

type Status report

message=No destination found for given partition key; errorCode=007001; statusCode=400

description The request sent by the client was syntactically incorrect (message=No destination found for given partition key; errorCode=007001; statusCode=400).

---

JBoss Web/2.1.12.GA-patch-03

Has anyone seen this before? I'm not sure if it's something Quickeebooks ought to support, but several of our users are getting it (all API requests fail).

—
Reply to this email directly or view it on GitHub.

[MattRogish]

Intuit has confirmed "I see some errors with the cluster id in our logs". Not sure what that means but it definitely is a bug on their end. I'm just wondering whether or not we should support error responses from Intuit that are not well-formed XML. In this case, an unexpected exception is thrown. Not sure if it would make sense to jam that HTML into the message object?

[ruckus]

I forget - does the HTTP response code come back as a 400? Do you remember? If it does then maybe we can not attempt an XML parse and just fail out a little more gracefully. If it does come back with a 200 but with this non-sense HTML then, well, it would be lame to then attempt to parse the HTML to generate a descriptive exception. Ugh.

[nickhammond]

@MattRogish Can you provide the request details? URL, headers, method, etc. As well as response status(I think it's a 400 judging by the details in the HTML body) and any headers sent back.

[MattRogish]

It was any request and unfortunately the token is no longer valid. According to intuit, it was that their QuickBooks Online account trial had expired, and we never heard back from the user(s) when we reached out to them.

[nickhammond]

@MattRogish I saw this issue yesterday but I didn't have logging turned on so I wasn't able to grab the full request details. I'll keep an eye on it, I believe it was on a delete request. The token I was using was still valid on the next request and everything. If I see it come up again I'll reply to this with more details.

[MattRogish]

I see. Well, ours was the GET on company meta data and failed every single time, on any request (GET invoices, customers, etc.). When I reached out to Intuit support, they said it appeared that the QuickBooks Online account trial had expired and no CC had been entered, so it was probably expected behavior.

[nickhammond]

Ah, good to know. I saw that in one of your earlier posts but that makes a bit more sense now.

[MattRogish]

It would be nice if Quickeebooks handled this in a nicer way instead of throwing an exception, but at least on our end it's so rare that I'm not too worried about it. We just catch this error then destroy the token, and inform the user to reconnect. If it happens intermittently (we didn't see it intermittently) then our approach is probably too conservative...

[nickhammond]

They seem to monitor their official support forum on StackOverflow.com fairly often, might be a good request to get in. You just have to tag a question with "intuit-partner-platform" -> http://stackoverflow.com/questions/tagged/intuit-partner-platform. I agree though that you should never get back HTML when you're requesting via XML, bad practice.

[nickhammond]

Finally got a full trace for this, still working on what's causing the issue for me.

Error raised: Nokogiri::XML::XPath::SyntaxError
Message: Undefined namespace prefix: //xmlns:FaultInfo/xmlns:Message
Error location: quickeebooks/lib/quickeebooks/online/service/service_base.rb:187:in `parse_intuit_error'

xml = parse_xml(body) # body is the response body when the returned status code is 400 or 500
error = {:message => "", :code => 0, :cause => ""}
fault = xml.xpath("//xmlns:FaultInfo/xmlns:Message")[0] # fails to find the proper namespace

Request/Response trace:

------ New Request ------
METHOD = post
RESOURCE = https://qbo.sbfinance.intuit.com/resource/accounts/v2/327151210
BODY(String) = "PageNum=1&ResultsPerPage=100"
HEADERS = {"Content-Type"=>"application/x-www-form-urlencoded"}
RESPONSE CODE = 400
RESPONSE BODY = <html><head><title>JBoss Web/2.1.12.GA-patch-03 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 400 - message=No destination found for given partition key; errorCode=007001; statusCode=400</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>message=No destination found for given partition key; errorCode=007001; statusCode=400</u></p><p><b>description</b> <u>The request sent by the client was syntactically incorrect (message=No destination found for given partition key; errorCode=007001; statusCode=400).</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/2.1.12.GA-patch-03</h3></body></html>

As mentioned before, it's when Intuit sends back HTML when they should be sending back XML. Nokogiri is trying to parse the document but it can't because it's HTML. We don't know the possible content/format for this document but it's also a standard Java error page.

I suppose we could parse it as HTML and grab the text of the document and then attempt to pull the error details from that.

Mainly this line:

message=No destination found for given partition key; errorCode=007001; statusCode=400

Thoughts?

[ruckus]

Yeah its lame. On one hand I don't necessarily want to bend over backwards to parse some obscure error that we shouldnt be receiving in the first place. What about just wrapping the Nokogiri error in our own ParseError or something or maybe ThisIsObscureAndYouDidNothingWrongException < StandardError just to let the user know?

[nickhammond]

I haven't had enough time yet to figure out what's triggering the error for me but it's my first API call after successfully authenticating a user. I'm just trying to list the accounts under a user account and it keeps on failing with that so it's not sporadic for me.

At the least we should rescue it when it fails to parse as XML and then yah maybe wrap it in an actual error but still undecided on the details we should provide with that error.

[whereisciao]

These HTML errors has been a torn in my side since working with QB in the last year. Digging further these errors are a result from their JBoss Server. The errors are presented as a status report. My plans are to raise a specific error for these "status report exceptions" so my other scripts can rescue them as opposed to other errors. And my rescue, I mean, send the request again.

Most of the details can be mapped to the existing Quickeebooks Exception class, but one. There is an additional error code that does not match any QBO documentation that I'm aware of. I might expose it so we can access it later.

Here is a link to my working branch:
https://github.com/whereisciao/quickeebooks/tree/error-handling-jboss-status-reports

Thoughts?

[ruckus]

I feel you - that error blows.

Whats the error code you see that doesn't map to anything?

Thanks for your continued diligence in the fact of QB evil.

On Aug 20, 2013, at 3:36 PM, Steven Chau [email protected] wrote:

These HTML errors has been a torn in my side since working with QB in the last year. Digging further these errors are a result from their JBoss Server. The errors are presented as a status report. My plans are to raise a specific error for these "status report exceptions" so my other scripts can rescue them as opposed to other errors. And my rescue, I mean, send the request again.

Most of the details can be mapped to the existing Quickeebooks Exception class, but one. There is an additional error code that does not match any QBO documentation that I'm aware of. I might expose it so we can access it later.

Here is a link to my working branch:
https://github.com/whereisciao/quickeebooks/tree/error-handling-jboss-status-reports

Thoughts?

—
Reply to this email directly or view it on GitHub.

[whereisciao]

During my investigation, I've found two codes. Where does 007001 and 006003 map to?

This is what I've deduced.

007001 => No destination found for given partition key
006003 => General IO error while proxying request