Closed jefflage closed 10 years ago
Hey @jefflage. Yeah, you could add a .then(logInfo, logError)
to the promise returned from .request
to see what the outcome is.
Does that help?
You should be able to use the following chaining pattern, since .timeout() simply returns a new promise:
var longRunningOperationPromise = fm_proxy.for_client(document.data._client).request(fmurl, false, config.event_download_config);
return longRunningOperationPromise.then(function callSucceeded(value){
console.info('Call eventually succeeded:', value);
return value;
}, function callFailed(reason){
console.error('Call failed:', reason);
return when.reject(reason); // or throw reason - works just as well; just remember that not producing an error will hide the failure by preventing error propagation!
}).timeout(config.event_load_timeout);
@rkaw92 Thanks for the nice example :)
duh. i was trying to over complicate it. thanks @rkaw92 and @briancavalier
@jefflage No prob, as always.
we're trying to track down an issue in prod where one of the async operations (an HTTP call using request) starts timing out on every call. we're struggling to track down what triggers it, and it occurred to me that i don't know if the call is never returning, or simple not returning within the time we pass to
.timeout()
. what happens when call eventually returns / promise resolves?we have the calls inlined like this:
can i just assign the promise returned from the first time to a variable and call
then()
on that to track when it eventually returns?