function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
jhartjhart 

Repeat UNKNOWN_EXCEPTION errors across multiple orgs; new IP security settings not the problem

Hello,

For two of our clients, we are getting repeated UNKNOWN_EXCEPTIONs whenever attempting to use the API in any way.

The last successful attempt was on 11/29 (for one client), and 11/30 (for the other).

In both cases, our IP ranges should have pre-populated the known IP list per the new Security settings.  I've also verified with one of the clients (the 11/29 client) that our full IP range is present in the new Security settings.

Here's a SOAP error dialog for that client:


Code:
SOAP::Transport::HTTP::Client::send_receive: POST https://www.salesforce.com/services/Soap/u/4.0
Accept: text/xml
Accept: multipart/*
Accept-Encoding: deflate
Content-Length: 681
Content-Type: text/xml; charset=utf-8
SOAPAction: ""

<—xml version="1.0" encoding="UTF-8"–>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <SOAP-ENV:Header>
    <CallOptions>
        <client xsi:type="xsd:string">*******</client>
    </CallOptions>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
    <namesp1:login xmlns:namesp1="urn:partner.soap.sforce.com">
        <username xsi:type="xsd:string">*****</username>
        <password xsi:type="xsd:string">*****</password>
        </namesp1:login>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 500 Internal Server Error
Date: Mon, 03 Dec 2007 22:44:33 GMT
Server:
Content-Length: 832
Content-Type: text/xml; charset=utf-8
Client-Date: Mon, 03 Dec 2007 22:44:33 GMT
Client-Peer: 204.14.234.33:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS In
corp.by Ref. LIABILITY LTD.(c)97 VeriSign
Client-SSL-Cert-Subject: /C=US/ST=California/L=San Francisco/O=Salesforce.com, Inc./OU=Applications/OU=Terms of use at www.verisign.com/rpa
(c)00/CN=www.salesforce.com
Client-SSL-Cipher: RC4-MD5
Client-SSL-Warning: Peer certificate not verified

<˜xml version="1.0" encoding="UTF-8"™>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://w
ww.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <soapenv:Fault>
   <faultcode>soapenv:Server</faultcode>
   <faultstring>UNKNOWN_EXCEPTION: An unexpected error occured. Please include this ErrorId if you contact support: 1360156535-4046</faultstring>
   <detail>
    <sf:fault xsi:type="sf:UnexpectedErrorFault" xmlns:sf="urn:fault.partner.soap.sforce.com">
     <sf:exceptionCode>UNKNOWN_EXCEPTION</sf:exceptionCode>
     <sf:exceptionMessage>An unexpected error occured. Please include this ErrorId if you contact support: 1360156535-4046</sf:exceptionMessage>
    </sf:fault>
   </detail>
  </soapenv:Fault>
 </soapenv:Body>
</soapenv:Envelope>

 

jhartjhart
Note: adding our IP blocks to the 11/30 client (the one whose IP security settings I hadn't verified) fixed the problem for them.  I don't know why we were getting an UNKNOWN_EXCEPTION rather than an "API Access Blocked" exception; and I still don't know why the 11/29 client - which also has our full IP blocks - isn't working.
jhartjhart
OK, now it's working on the other client too.  Nothing has changed on our end; maybe the IP settings took a while to propagate?  Or perhaps our client changed some other config that was keeping the IP settings from being honored?
prbprb
Did anyone find out what the cause of this was?  Since we rolled out the new IP filter I have been getting this error every 5 requests or so w/a remote API connection.
jhartjhart
prb - I haven't heard anything.  We still see it intermittently as well, but not the 100%-of-the-time-for-one-client problem that I originally posted about.

Instead we're seeing an every-now-and-again error that goes away on retry, so no particular query or transaction is the culprit.

The incidence of this error seems to have increased since the new settings, but is much lower across our client base than the 1-in-5 rate that you're seeing.  For the past 24 hours we're at 32 errors over tens of thousands of API transactions across many clients.
QueballQueball
I am getting a very simular error too.  So far no word from SF.  For myself it has been happening off and on since at least the 9th.
prbprb
Well I opened a case w/customer support and I'll post anything I find out.  Are you pooling the SF connection or do you login with a fresh connection for each transaction?  Just wondering if that has any affect on how often the error occurrs?  I'm using a rudimentary connection pool that just hangs on to a session ID for 30 minutes but I'm considering just logging in for each transaction b/c the API has gotten so flaky lately.
jhartjhart
Yes - we retain our SessionIDs for as long as possible.  We only re-login when we have to (when SFDC tells us our old session ID has expired).  I believe this means that some of our API sessions can be days long if there's sufficient activity.  I've never before seen problems with long-held Session IDs, so it hasn't occurred to me that it might be related.