When an Exchange instance returns a http 500 error with an error that isn’t EXACTLY a soap error, an orphaned uncaught exception is thrown and the method never returns

[perbergland]

Verified in 0.15.3 and 0.13.2.

The root cause is that the error handler for status 500 creates an instance of EwsServiceXmlReader which will crash if xmlDoc is undefined or later if the exactly correct SOAP error properties aren’t included.

Since the default behaviour for nodejs is to perform a process.exit on uncaught exceptions like this, this leads to serious crashes and the method will hang since it crashes in the code that is supposed to invoke the errorDelegate

[perbergland]

This is my complete stack trace for 0.13.2

[xmldom error]	invalid doc source 
@#[line:0,col:undefined]
/opt/bundle/bundle/programs/server/npm/node_modules/ews-javascript-api/js/Core/EwsXmlReader.js:19
        this.jsObject = xml2js.parseXMLNode(this.xmlDoc.documentElement, true);
                                                        ^

TypeError: Cannot read properties of undefined (reading 'documentElement')
    at new EwsXmlReader (/opt/bundle/bundle/programs/server/src/js/Core/EwsXmlReader.ts:43:57)
    at new EwsServiceXmlReader (/opt/bundle/bundle/programs/server/src/js/Core/EwsServiceXmlReader.ts:18:9)
    at FindItemRequest.ProcessWebException (/opt/bundle/bundle/programs/server/src/js/Core/Requests/ServiceRequestBase.ts:314:30)
    at /opt/bundle/bundle/programs/server/src/js/Core/Requests/SimpleServiceRequestBase.ts:70:55
    at processTicksAndRejections (node:internal/process/task_queues:105:5)

Node.js v22.13.1

[perbergland]

It seems that the payload must even be a valid SOAP error for the code not to crash. The only workaround I have thought of so far is to insert a proxy between this code and the server…

[perbergland]

It is the "catch" callback (parameter 2 to .then) in

ews-javascript-api/src/js/Core/Requests/SimpleServiceRequestBase.ts

Line 71 in 67c1920

if (errorDelegate) errorDelegate(this.ProcessWebException(resperr) || resperr);

that throws a synchronous error by invoking ProcessWebException and then everything breaks.

[perbergland]

Solution suggestion:

Ensure that ProcessWebException cannot throw by adding resilience.
Maybe even add a guarding try/catch around the call and just invoke errorDelegate(err) if an error is thrown

[jona-wilmsmann]

Confirming this with the exact root cause and a minimal fix — just hit it in production.

The throw is in ProcessWebException (Core/Requests/ServiceRequestBase). On status == 500 it runs:

var reader = new EwsServiceXmlReader(webException.responseText, this.Service);
soapFaultDetails = this.ReadSoapFault(reader.JsObject);

EwsXmlReader's constructor does this.xmlDoc = parser.parseFromString(rawXML, "text/xml") and immediately reads this.xmlDoc.documentElement with no null check. When a 500 body isn't valid XML (an empty body, an HTML/proxy error page, a truncated response), parseFromString returns undefined and .documentElement throws TypeError: Cannot read properties of undefined (reading 'documentElement').

Why the method "never returns": the throw happens inside the .then() fulfillment callback in InternalExecute, before errorDelegate is called. So the outer new Promise((successDelegate, errorDelegate) => …) is never settled — the request promise neither resolves nor rejects — and the throw escapes as an unhandled rejection. A try/catch at the call site can't catch it.

The call site already assumes this can be tolerated: errorDelegate(this.ProcessWebException(xhrResponse) || xhrResponse) — the || xhrResponse only makes sense if ProcessWebException may return null. The original C# (still in the comments right above) caught the deserialization failure and returned null. Restoring that fixes it:

try {
    var reader = new EwsServiceXmlReader(webException.responseText, this.Service);
    soapFaultDetails = this.ReadSoapFault(reader.JsObject);
} catch {
    // Non-XML 500 body (empty / HTML error page / truncated) — no SOAP fault to parse.
    soapFaultDetails = null;
}

Now a malformed 500 falls through to || xhrResponse, errorDelegate fires, and the promise rejects cleanly instead of hanging + throwing. (Equivalently, a null-guard in EwsXmlReader's constructor before it reads .documentElement.)