DSCallback fires when DSResponse failed

[sashonk]

Hello!
SmartClient v10.1p_2016-01-16/LGPL Development Only

I make a call to perfromCustomOperation() on an datasource and pass DS callback. Then the error occurs on the server side and the response status is -1, but the callback is still fired. I tried to play with willHandleError property of a DS request, but unsuccessfully.

Then I debugged and found this code in ISC_DataBinding.js :

    fireResponseCallbacks : function (dsResponse, dsRequest, rpcResponse, rpcRequest) {
 
        if (!dsResponse.clientContext) dsResponse.clientContext = {};
 
        if (dsResponse.status >= 0) {
            // on success, notify ResultSets
            isc.DataSource.handleUpdate(dsResponse, dsRequest);
        } else if (!dsRequest.willHandleError) {
            isc.RPCManager._handleError(dsResponse, dsRequest);
        }
 
        // fire callbacks:
                        // passed directly to a DataSource method, eg ds.fetchData()
        var callbacks = [dsRequest._dsCallback,
                        // secondary convenience callback, see ActionMethods::buildRequest()
                         dsRequest.afterFlowCallback],
            firedCallbacks = [];
 
        for (var i = 0; i < callbacks.length; i++) {
 
            var callback = callbacks[i];
 
            // paranoid duplicate callback check
            if (firedCallbacks.contains(callback)) {
                this.logWarn("Suppressed duplicate callback: " + callback);
                continue;
            }
 
            var callbackResult = this.fireCallback(callback, "dsResponse,data,dsRequest",
                                                    [dsResponse,dsResponse.data,dsRequest]);
 
 
            // the primary callback, which completes the basic dataSource flow, can stop
            // further processing by returning false.  This is intended to allow flow code to
            // signal fundamental errors that high-level user code isn't expected to handle.
            if (rpcRequest && rpcRequest.willHandleError && callbackResult === false) {
                //>DEBUG
                this.logDebug("performOperationReply: Further processing cancelled by callback");
                //<DEBUG
                break;
            }
 
            // If transaction has been suspended, stop processing callbacks
            // Can happen on EG login failure
 
            if (rpcResponse) {
                var transaction = isc.RPCManager.getTransaction(rpcResponse.transactionNum);
                if (transaction && transaction.suspended) return;
            }
        }
 
    },

It turns out that the "primary" callback (wich is passed directly to datasource method) is always fired regardless response' status. According to the docs on
http://www.smartclient.com/docs/10.1...e..DSCallback:

Note that if the request encounters a low-level error (such as 500 server error), by default the callback will not be fired, instead, DataSource.handleError() is called to invoke the default system-wide error handling. Set willHandleError:true to have your callback invoked regardless of whether there are errors, however, make sure your callback properly handles malformed responses when DSResponse.status is non-zero.

This is my code:

                                    filterDs.performCustomOperation('fetch', filter, function(rs, data, rq){
                                        if(rs.status < 0){
                                            alert('status=' + rs.status);
                                            return;
                                        }                                      
                                         alert('OK' );                                                                                
                                    });

In result I see both message box of default RPCManager.handleError() and JS alert (see attached screenshot)
In order to cancel DS callback execution in all requests I have to manually check the response status in the DS callback

If this is a bug - please, clarify when it will be fixed. If it is not - then the online documentation is incorrect.