Ext Direct exception issue

[badgerb1]

I'm working with Ext Direct and I think I've found a bug. When an exception is sent back from the server, the callback handler sends event.getResult() as the "response" parameter to the process response function. Then the processResponse function calls setException(operation, response). Since the event.result is null, and that is what is getting put into the response parameter, setException get's null for the response. Then in setException, it tries to do a getMessage() from the response passed in and throws a null reference error and fails completely.

I attempted to return an object that has a message field in it as the result, but that doesn't work either since the system is trying to call the getMessage() function on the returned result.

To trace this through, the error occurs at line 40153 in the touch-all-debug.js

setException: function(operation, response) {
        operation.setException(response.getMessage());
    },

which is called from line 32358

           me.setException(operation, response);

response is set from line 40142 where the response parameter comes from event.getResult()

createRequestCallback: function(request, operation, callback, scope) {
        var me = this;


        return function(data, event) {
            me.processResponse(event.getStatus(), operation, request, event.getResult(), callback, scope);
        };
    },

and event is the individual Ext Direct responses from line 50646

for (ln = events.length; i < ln; ++i) {
                event = events[i];
                transaction = me.getTransaction(event);
                me.fireEvent('data', me, event);
                if (transaction) {
                    me.runCallback(transaction, event, true);
                    Ext.direct.Manager.removeTransaction(transaction);
                }
            }

Not sure at this point how to fix this as the trace runs pretty deep. Easy to test though just have the Ext.Direct server return an exception type response. I don't think there's any way to return a json result that will work as an exception.

Example response json that causes error
[{"action":"MobileServices","message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading","method":"createDevice","result":{"message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading"},"tid":2,"type":"exception"},{"action":"MobileServices","message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading","method":"createDevice","result":{"message":"id to load is required for loading; nested exception is java.lang.IllegalArgumentException: id to load is required for loading"},"tid":3,"type":"exception"}]

Sorry for being so long winded it's kind of complex and I'm hoping I described it well enough.

Thanks
Bob

[jeroenwalter]

I too have encountered this bug.
It seems to me that the entire ext.direct library has some serious issues with returned exceptions and with invalid JSON responses (e.g. a php error).

I'm still trying to come up with a workable solution, but I think that the Sencha Team should perform some serious tests of ext.direct.

[mallowtek]

I've got the same badgerb1 issue. Same causes, same consequences ?

Anybody found a tweek excluding catching events instead of exception as I want to keep same ext.direct code for both extjs and sencha touch client.

Ex direct is simple but not well documented. Perhaps Sencha could open a doc section for it, with sample for exception handling.

[ampro]

I now have a Siesta unit test that is reproducing this exception bug. I've had a dig through the code and come up with a fix for Sencha Touch/ExtJS. It's not pretty but I don't see any other way.

The docs ...

Ext-direct-RemotingProvider.actions states that the callback from a direct RPC include an event argument (e) from which you can get the exception message via event.getMessage() and the success/failure status via event.getStatus(). This is only place that I can find that documents the schema of the event
object when an exception occurs.

Touch 2.1.1 (A slightly different but equivalent code sample is documented in ExtJS 4.1.3)

TestAction.multiply(
    2, 4, // pass two arguments to server, so specify len=2
    // callback function after the server is called
    //     result: the result returned by the server
    //     e: Ext.direct.RemotingEvent object
    function(result, e) {
        var t = e.getTransaction();
        var action = t.action; // server side Class called
        var method = t.method; // server side method called
        if (e.getStatus()) {
            var answer = Ext.encode(result); // 8
        } else {
            var msg = e.getMessage(); // failure message
        }
    }
);

The bug ...

Ext.define('Ext.data.proxy.Direct', {
    extend: 'Ext.data.proxy.Server',
    alternateClassName: 'Ext.data.DirectProxy',
    alias: 'proxy.direct',
    requires: ['Ext.direct.Manager'],
    ....
    createRequestCallback: function(request, operation, callback, scope) {
        var me = this;
        return function(data, event) {
            me.processResponse(
              event.getStatus(), operation, request, event.getResult() /* => response */, callback, scope);
        };
    },

    // @inheritdoc
    setException: function(operation, response) {
          ///  BUG: message => event.getResult().getMessage()  - but  should be event.getMessage()
        operation.setException(response.getMessage()); 
    },
    ....
}

The fix ...

In Direct.createRequestCallback() we need replace ...

    me.processResponse(event.getStatus(), operation, request, event.getResult(), callback, scope);

with ...

   me.processResponse(event.getStatus(), operation, request, event, callback, scope);

... so we can later perform response.getMessage() and obtain event.getMessage().

This would also make it look much like the other calls to processResponse() ...

data\proxy\Ajax.js(329):
 me.processResponse(success, operation, request, response, callback, scope);
data\proxy\JsonP.js(229): 
me.processResponse(success, operation, request, response, callback, scope);

Looking at the existing code below for Server.processResponse() ...

We need to ensure that the behavior for other proxies is unchanged but that this call ...

resultSet = reader.process(response);

becomes ...

resultSet = reader.process(response.getResult());

... but only for the Direct proxy.

So I propose that it become ...

    resultSet = reader.process(me.getResponseResult(response));

Where Server.getResponseResult(response) is a noop that just returns response and is inherited by other proxies while Direct.getResponseResult(reponse) returns response.getResult()

The only other behavioral issue is the calls to ...

me.fireEvent('exception', this, response, operation);

.. but I suspect that they were sending the wrong response value as well and that this change will fix them too.

Finally there also a call to

    this.fireEvent('exception', this, response, operation);

that I suspect should be

    me.fireEvent('exception', this, response, operation);

The Direct proxy also needs a missing a unit test case that would have picked this up.

data\proxy\Server.js(222): 
    processResponse: function(success, operation, request, response, callback, scope) {
        var me = this,
            action = operation.getAction(),
            reader, resultSet;


        if (success === true) {
            reader = me.getReader();


            try {
                resultSet = reader.process(response);  
            } catch(e) {
                operation.setException(e.message);


                me.fireEvent('exception', this, response, operation);
                return;
            }


            // This could happen if the model was configured using metaData
            if (!operation.getModel()) {
                operation.setModel(this.getModel());
            }


            if (operation.process(action, resultSet, request, response) === false) {
                this.fireEvent('exception', this, response, operation);
            }
        } else {
            me.setException(operation, response);
            /**
             * @event exception
             * Fires when the server returns an exception
             * @param {Ext.data.proxy.Proxy} this
             * @param {Object} response The response from the AJAX request
             * @param {Ext.data.Operation} operation The operation that triggered request
             */
            me.fireEvent('exception', this, response, operation);
        }


        //this callback is the one that was passed to the 'read' or 'write' function above
        if (typeof callback == 'function') {
            callback.call(scope || me, operation);
        }


        me.afterRequest(request, success);
    },

[TommyMaintz]

Thank you ampro for the extensive debugging and testing you have done on this. I have incorporated your proposed fixes into the codebase for Touch 2.2.1.

Best,
Tommy