Rally SDK2 Lookback API - Javascript - How to catch exceptions during query execution

[Gregory Garcia]

Hello,

I'm using the Rally SDK2 Lookback API from Javascript to retrieve some features at some dates in the past. It appears that, sometimes, my store fails to load data and triggers a network exception I'm unable to catch... 

I tried to add some exception handlers at many place but there are never triggered: in the store, in the model, in the proxy, as events, as an exceptionHandler property, etc.

Here is my piece of code:

// Load the features from Rally
function loadFeaturesHistorical() {
	console.log(' - search for features...');

	var features = Ext.create('Rally.data.lookback.SnapshotStore', {
		fetch: ['FormattedID', '_ValidFrom', '_ValidTo'],
		context: {
			workspace: gvRallyWorkspace,
			project: gvRallyProject,
		},
		filters: [{property: '_TypeHierarchy', operator: '=', value: 'PortfolioItem/Feature'}, 
			{property: '__At', value: gvAt}, 
			{property: 'Release', operator: '=', value: gvSelectedRelease.rallyRetrievedInfos.ObjectID}
		],
		listeners: {
			load: loadedFeaturesHistorical,
			scope: this
		},
		exceptionHandler: function (proxy, response, operation) {
			console.log('Historical data loading exception - Z');
		}
	});
	features.proxy.listeners = [
		{
			exception: function(proxy, options, response) {
				console.log('Historical data loading exception - A');
			}
		},
		{
			loadexception: function(proxy, options, response) {
				console.log('Historical data loading exception - B');
			}
		}
	];
	features.model.proxy.events.exception.listeners = [
		{
			exception: function(proxy, options, response) {
				console.log('Historical data loading exception - C');
			}
		},
		{
			loadexception: function(proxy, options, response) {
				console.log('Historical data loading exception - D');
			}
		}
	];
	features.listeners = [
		{
			exception: function(proxy, options, response) {
				console.log('Historical data loading exception - E');
			}
		},
		{
			loadexception: function(proxy, options, response) {
				console.log('Historical data loading exception - F');
			}
		}
	];
	features.on('exception',function(store, records, options){
		console.log('Historical data loading exception - G');
	},this);
	features.load();
};

So, in case of loading exception, I would expect the console to display a message: "Historical data loading exception - X".
Here is the console output (stack trace) that appears when an exception occurs and is not caught by my code:

Thank for your suggestions!

[Nik Antonelli]

Woah, Gregory!

What are you trying to catch?  The normal route is to have a look at whether it was successful: https://rally1.rallydev.com/docs/en-us/saas/apps/2.1/doc/index.html#!/guide/lookback_api and then get the error: https://rally1.rallydev.com/docs/en-us/saas/apps/2.1/doc/index.html#!/api/Ext.data.Operation-method-wasSuccessful

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[Gregory Garcia]

Thanks again for your help Nik :-)

Do you mean this way?

// Load the features from Rally
function loadFeaturesHistorical() {
	console.log(' - search for features...');

	var features = Ext.create('Rally.data.lookback.SnapshotStore', {
		fetch: ['FormattedID', '_ValidFrom', '_ValidTo'],
		context: {
			workspace: gvRallyWorkspace,
			project: gvRallyProject,
		},
		filters: [{property: '_TypeHierarchy', operator: '=', value: 'PortfolioItem/Feature'}, 
			{property: '__At', value: gvAt}, 
			{property: 'Release', operator: '=', value: gvSelectedRelease.rallyRetrievedInfos.ObjectID}
		],
		listeners: {
			load: loadedFeaturesHistorical,
			scope: this
		}
	});
	features.load({
					callback: function(result, operation) {
						if(!operation.wasSuccessful()) {
							console.log('Historical data loading exception');
						}
					}
				});
};

After a few tries, I got a server error that was not caught. My log message is not raised at all:

During another execution that was going well, I closed my Windows session and reopen it. I got this kind of exception and my log message is not raised, I didn't catch the exception:

[Nik Antonelli]

Hi Gregory, on a side note - why do you have loadFeaturesHistorical as the 'load' listener? Won't that just recursively call the same function over and over again?

If you use the callback as you have added in the features.load config section, then you shouldn't need the listener.

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[Gregory Garcia]

My load listener does not call loadFeaturesHistorical but loadedFeaturesHistorical :-)

I agree that the callback will allow me to handle my call to loadedFeaturesHistorical  without using the listener, I will refactor all my calls once I can handle the exceptions correctly.

[Nik Antonelli]

Oh Yeah! Sorry, I misread the text.

In your app, can you change it so that it loads sdk-debug.js instead of the minimised sdk.js and then rerun to get an error? It will help locate the place where the error is (mis-)handled in the stack trace. I am currently making guesses as to which bit of code is actually being run.

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[Gregory Garcia]

Of course Nik, thanks for your investigations!

Here is the stack with the following include (for the moment, it is being executed outside from Rally):

<script type="text/javascript" src="https://rally1.rallydev.com/apps/2.1/sdk-debug.js?debug=true"></script>​

[Nik Antonelli]

Hi Gregory,

Th next thing I would do in this situation is to set the debugger (and this looks like Chrome) to pause on caught exceptions. Then you can trawl back through the stack and the debugger sets the environment to that point in the stack trace.

The Ext code is allowing the  error to propagate right through the code with the 'response' variable as null until it gets to that point. I think you will have to click on each of the stack points and see where the null comes from. It may be being passed into us from the basic networking stuff that we have no control over, or it might even be a known bug in ExtJs4.2 (which our SDK is based on).

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[Gregory Garcia]

Ok, thanks four your help Nick ;-) I confirm I'm using Chrome.

I'll debug that later, for the moment I simply added a timer that will consider there was an exception after a while and retry to load the data... When data has been loaded, I remove the timer. This is ugly but, as a temporary workaround, it helps.

Called just before trying to query the lookback API:

// Start a timer to restart execution in case of not completed in time (unable to catch callback exceptions like server does not respond, network connexion loast, etc.)
var minutesToWaitUntilFailure = 5 * 60 * 1000; // 5 min (expressed in milliseconds)
gvTimerIdHistoricalDataDidNotCompleteInTime = setTimeout(() => {
	historicalLoadingExceptionMgt('EXCEPTION - Historical data loading did not complete in time, cancel and restart');
}, minutesToWaitUntilFailure);​

Called when the data has been retrieved:

// Stop the timer waiting for loading completion
if (gvTimerIdHistoricalDataDidNotCompleteInTime) {clearTimeout(gvTimerIdHistoricalDataDidNotCompleteInTime);}

I'll keep you posted if I can achieve to identify what goes wrong thanks to the Chrome debug tools.

[Nik Antonelli]

Hi Gregory,

This looks to be a 'feature' of ExtJs 4.2. I trawled through the code to find that for network errors, ExtJs sets the response to null. Have a look at the sdk-debug.js file at lines 76584, 76590 and 76601. The first parameter of handleResponse is set to null directly and then the browser barfs with a null reference exception later down the stack.

This is not something that there is a fix for that I can see.

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[Gregory Garcia]

Thanks for pointing that Nik! Do you think this is no catchable at all in my app?

[Nik Antonelli]

The only way I know to pick up exceptions is with the try/catch combo. However, I have no clue as to where that work best in this code - most of it is buried in the sdk.js file which you have no control over.

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[Gregory Garcia]

Yes, the try/catch does not work in this asynchronous code... I feel it is like if the SDK was raising the exception directly to the browser with no way to catch it from the application.

Anyway, thanks for your help again :)