We Keep Coding

Javascript: reject still calling next then in the sequence

I am recursively calling a function which returns a Promise, but i am noticing that the next then is called even if i am rejecting with error. Below is the relevant part of the code.
const applyFilters = (counter) => {
return new Promise((resolve, reject) => {
let filter = filters[counter];
if(filter) {
applyStep(filter).then(promiseTimeout(filter.delay), function(err) {
console.log('reject with error');
reject(err);
}).then(function(res) {
console.log('still executing after reject');
resolve(applyFilters(++counter).catch(function(err) {
reject(err);
}));
});
} else {
resolve(true);
}
});
};
const applyStep = (step) => {
if(step.step_type == 'filter') {
return worksheet.applyFilterAsync(step.name, values, 'replace');
} else if(step.step_type == 'parameter') {
return workbook.changeParameterValueAsync(`${step.name}`, value);
} else {
return Promise.resolve(true);
}
};
I am seeing on console
reject with error
still executing after reject
Is this the expected behaviour, may be I am missing something. Any help in understating this further will be really great. Thanks.

You are passing the second callback to then, which handles the error (in this case by rejecting the outer promise), and then fulfills the promise returned by the then() call with the callback return value (undefined). The next then() in the chain will be executed once that promise is fulfilled.
I could tell you how to work around this problem by using a different then/catch structure, but really you need to avoid the Promise constructor antipattern here!
function applyFilters(counter) {
if (counter >= filter.length)
return Promise.resolve(true);
const filter = filters[counter];
return applyStep(filter)
.then(promiseTimeout(filter.delay))
.then(res => applyFilters(++counter));
}

after adding a listener to a Promise, should I use the original promise or the new one?

I have some javasript code that takes an existing promise
(say, the promise returned by fetch()) and adds value
(say, then/catch listeners for debugging, or maybe more):
let myFetch = function(url) {
return fetch(url).then(function(value) {
console.log("fetch succeeded: value=",value);
return value;
}.catch(function(reason) {
console.log("fetch failed: reason=",reason);
throw reason;
});
};
I found myself modifying the above code so that the listeners are added only if some condition is true:
let myFetch = function(url) {
let promise = fetch(url);
if (some condition) {
promise = promise.then(function(value) {
console.log("fetch succeeded: value=",value);
return value;
}.catch(function(reason) {
console.log("fetch failed: reason=",reason);
throw reason;
});
}
return promise;
};
Now I'm wondering, does it really make sense for myFetch to return the new promise returned by "then"
(actually catch which is shorthand for another "then") as above,
or would it make more sense for it to return the original promise (with the added listeners)?
In other words, I'm thinking of leaving out the second "promise =",
so that the code will look like this instead:
let myFetch = function(url) {
let promise = fetch(url);
if (some condition) {
promise.then(function(value) {
console.log("fetch succeeded: value=",value);
return value;
}.catch(function(reason) {
console.log("fetch failed: reason=",reason);
throw reason;
});
}
return promise;
};
Is that effectively different from the previous version?
Is either version preferable, and if so, why?

If your only use case is logging something in then/catch – it shouldn't matter as long as everything goes well. Things get more messed if you get an exception. Consider these two examples:
Return original promise
function myFetch() {
let promise = new Promise(function (resolve, reject) {
resolve(100);
});
promise.then(function () { throw new Error('x'); });
return promise;
}
myFetch().then(function () {
console.log('success!');
}).catch(function (e) {
console.error('error!', e)
});
The result is success and the error thrown in the inner then might get swallowed in some promise libraries (although the most popular ones such as Bluebird handle this and you get additional error Unhandled rejection Error: x).
The error might also get swallowed when using native Promises in some environments.
Returning modified promise
function myFetch() {
let promise = new Promise(function (resolve, reject) {
resolve(100);
});
promise = promise.then(function () { throw new Error('x'); });
return promise;
}
myFetch().then(function () {
console.log('success!');
}).catch(function (e) {
console.error('error!', e)
});
Now the result is error! Error: x.

Well, if your success handler returns the value and your rejection handler throws the error - then it is basically the identity transformation for the promise.
Not only do you not need to do that promise = promise.then you don't even need to return the values:
let myFetch = function(url) {
let promise = fetch(url);
if (some condition) {
promise.then(function(value) {
console.log("fetch succeeded: value=",value);
}.catch(function(reason) {
console.log("fetch failed: reason=",reason);
});
}
return promise;
};
That said, if you're using ES6 and let, you can use arrow functions which makes this a little nicer anyway:
let myFetch = function(url) {
let promise = fetch(url);
if (some condition) {
promise.then(value => console.log("fetch succeeded: value=",value))
.catch(reason => console.log("fetch failed: reason=",reason));
}
return promise;
};
Some promise libraries like bluebird provide a tap utility for this. The only problem is that if ever fetch adds support for promise cancellation, you are breaking the chain with the if (some condition) handler if you're not chaining it.

You're promise branching. In the second case, you're effectively branching the promise chain into two promise chains, because once a caller calls myFetch:
myFetch("localhost").then(request => { /* use request */ } );
then promise will have had .then called on it twice (once inside myFetch to do the console logging, and again here).
This is fine. You can call .then on the same promise as many times as you like, and the functions will execute together in the same order whenever promise resolves.
But, importantly, each function represents a branch off of the original promise, independent of every other branch. This is why you don't need to return or rethrow anything after your console.log: Nobody's listening on that branch, specifically, the caller of myFetch is not affected.
This is a good fit for logging IMHO, but there are subtle timing and error handling differences to be aware of when doing anything more:
var log = msg => div.innerHTML += msg + "<br>";
var myFetch = url => {
var p = Promise.resolve({});
p.then(() => log("a")).then(() => log("b"));
return p;
}
myFetch().then(() => log("1")).then(() => log("2")).catch(log); // a,1,b,2
<div id="div"></div>
This emits a,1,b,2. As you can see, there are two chains going on here, advancing in parallel. It makes sense when you think about when promise is resolved, but it can be surprising.
The other subtlety is that error handling is also per branch (one branch will never fail another). In fact, the above code has a bug. Did you spot it? There should be a catch after .then(() => log("b")), or errors about anything you do in that branch end up unhandled or swallowed in some environments.

NodeJS Promise behaviour query

I was experimenting with Promise in nodejs to better understand how it works. I have partially working code, but I am not sure if I am using it correctly. My intention is to pass error or correct result back to caller function. This seem to get complicated with all these callbacks. Here is what I have so far.
//This is my main CALLER function
function query_mcafee_mssql_type(database, node_name, type) {
return new Promise(function (fulfill, reject) {
switch (type) {
case "currentDefinitionDate":
computeCurrentDefinitionResult(database, node_name)
.then(function (result) {
console.log('query_mcafee_mssql_type' + result);
fulfill(result);
});
break;
}
});
}
function computeCurrentDefinitionResult(database, node_name) {
return new Promise(function (fulfill, reject) {
var leaf_sql_query = "SELECT * FROM "+ JSON.stringify(database) +".dbo.EPOLeafNode WHERE NodeName=" + "'" + node_name + "'";
query_mcafee_mssql(leaf_sql_query)
.then(function (LeafNode) {
if (LeafNode == undefined) {
fulfill(LeafNode);
} else {
return LeafNode;
}
})
.then(function (LeafNode) {
console.log('computeCurrentDefinitionResult' + LeafNode);
var product_properties_sql_query = "SELECT * FROM "+ JSON.stringify(database) +".dbo.EPOProductProperties WHERE ParentID=" + "'" + LeafNode.AutoID + "'" + "AND ProductCode LIKE 'VIRUSCAN%'";
return query_mcafee_mssql(product_properties_sql_query);
})
.then(function (ProductProperty) {
if (ProductProperty == undefined) {
fulfill(ProductProperty);
} else {
return ProductProperty;
}
})
.then(function (ProductProperty) {
fulfill(ProductProperty.DATDate);
});
});
}
function query_mcafee_mssql(sql_string) {
return new Promise(function (fulfill, reject) {
query_mssql(mcafee_config, sql_string)
.then(function (sql_response) {
fulfill(sql_response);
console.log('query_mcafee' + sql_response);
});
});
}
function query_mssql(config, sql_string){
return new Promise(function (fulfill, reject) {
var connection = new sql.Connection(config, function(err) {
// ... error checks
if (err) {
console.log('connection to mssql has failed');
//throw err;
fulfill();
} else {
// Query
var request = new sql.Request(connection);
request.query(sql_string, function(err, recordset) {
// ... error checks should go here :
if (err) {
console.log('requst query error');
fulfill();
} else {
// output query result to console:
//console.log(recordset);
fulfill(recordset);
}
});
}
});
});
}
My main caller function is query_mcafee_mssql_type(). I use Promise to allow the execution of the query. Once that is done, if its an error, I would like "undefined" to returned else the correct result to returned to the caller.
As per my understanding, fulfill and reject callbacks decide the fate of Promise.
The top most in call stack is function query_mssql(). My assumption was that once I call "fulfill" with result if success or return fulfill() empty if error.
The function above that is query_mcafee_mssql() which is oblivious to error or success and just passes on the result.
The function computeCurrentDefinitionResult() is where all the problem arises. I need to make two sql query one after the other. However if first query fails then I don't see any point in proceeding with next query that means
query_mcafee_mssql(leaf_sql_query)
.then(function (LeafNode) {
if (LeafNode == undefined) {
fulfill(LeafNode);
} else {
return LeafNode;
}
})
I do not want rest of the .then to be executed as it does not make sense if LeafNode is undefined. I want to return the LeafNode value back to its caller. However if I return fulfill(), the code flow seem to move to next .then. If I use, reject(), the caller query_mcafee_mssql_type() .then block is not getting called. The relevant block is show below.
computeCurrentDefinitionResult(database, node_name)
.then(function (result) {
console.log('query_mcafee_mssql_type' + result);
fulfill(result);
});
- How can I return the actual result from computeCurrentDefinitionResult() ??
- Does all the functions need to return "Promise" to achieve what I am doing?
- Why does the code patch not return from the function after "fulfill()" is called?
- Is there a need to use "return" in these function blocks?
Any help would be appreciated. Thanks.

From your code, I got a feeling that you have no idea about the correct usage of resolve and reject in Promise. Here is the right one.
function query_mssql(config, sql_string){
return new Promise(function (resolve, reject) {
var connection = new sql.Connection(config, function(err) {
// ... error checks
if (err) {
return reject(err);
}
// Query
var request = new sql.Request(connection);
request.query(sql_string, function(err, recordset) {
// ... error checks should go here :
if (err) {
return reject(er);
}
// output query result to console:
//console.log(recordset);
resolve(recordset);
});
});
});
}
//Then use it like this
query_mssql(config,sql_string)
.then(function(LeafNode){
//query success
console.log(LeafNode);
}).catch(function(er){
//query failed,
console.log(er);
});

Node.js Promise - Shouldn't code wait until .then is complete()?

I am confused by this async behavior.
When token is false, refreshToken() function runs but the createTokenFile() doesn't wait for it to finish.
Shouldn't var tokenDate = new Date(token.expires); wait after callApiToken().then(function() {refreshToken();}) to finish before executing?
function createTokenFile() {
console.log("No token-file.json file found. " .red +
"Please complete for a new one." .red);
return callApiToken().then(function() {
refreshToken();
});
}
function checkExpiredToken() {
return new Promise(function(resolve, reject) {
if (!token) {
refreshToken();
}
var tokenDate = new Date(token.expires);
var utc = new Date().toUTCString();
var now = new Date(utc);
}
function refreshToken() {
try {
var tokenFile = path.join(__dirname, 'token-file.json');
console.log(tokenFile);
return token = JSON.parse(fs.readFileSync(tokenFile, {encoding: 'utf-8'}));
} catch (err) {
if (err.code !== 'ENOENT') {
throw err;
} else {
return createTokenFile();
}
}
}
UPDATED with refreshToken()

Shouldn't var tokenDate = new Date(token.expires); wait after callApiToken().then(function() {refreshToken();}) to finish before executing?
No - it's not in a .then() callback that would wait for the promise to resolve. It only waits until the promise is created - but the promise resolution (that you call "finish") is asynchronous. Notice that promises are not magic, they're just callbacks.
To fix your code,
in createTokenFile you need to return the refreshToken() from the then callback
checkExpiredToken should not use the Promise constructor
refreshToken should always return a promise
there's no reason why refreshToken would read the file synchronously
you shouldn't cache the token as a global variable containing the value
function createTokenFile() {
console.log("No token-file.json file found. " +
"Please complete for a new one.");
return callApiToken();
}
function checkExpiredToken() {
return (tokenPromise || refreshToken())
.then(function(token) {
var tokenDate = new Date(token.expires);
var utc = new Date().toUTCString();
var now = new Date();
});
}
function refreshToken() {
var tokenFile = path.join(__dirname, 'token-file.json');
console.log(tokenFile);
return tokenPromise = readFileAsync(tokenFile, {encoding: 'utf-8'}))
.then(JSON.parse)
.catch(function(err) {
if (err.code !== 'ENOENT') {
throw err;
} else {
return createTokenFile().then(refreshToken);
}
});
}
(where readFileAsync is a promisified version of fs.readFile)

Promise do not de-synchronize code. An function that is asynchronous will always be so. Therefore if refreshToken is asynchronous then it's use above will not wait for it to complete before moving on.
Your code sample leaves too much to the imagination (not to mention syntactically incorrect) so a better answer is not available. Perhaps try recreating the situation in jsbin.com or jsfiddle.net.

Bluebird Promise Cancellation

Say I have the following Promise chain:
var parentPromise = Promise.resolve()
.then(function () {
var condition = false;
if (condition) {
return parentPromise.cancel('valid reason');
} else {
return Promise.resolve()
.then(function () {
var someOtherCondition = true;
if (someOtherCondition) {
console.log('inner cancellation');
return parentPromise.cancel('invalid reason');
}
});
}
})
.catch(Promise.CancellationError, function (err) {
console.log('throwing');
if (err.message !== 'valid reason') {
throw err;
}
})
.cancellable();
The above never enters the catch.
If we swap condition to true, the inner cancellation is never hit, but the catch is still not triggered.
removing the .cancellable at the end , and replacing all instances of parentPromise.cancel() with explicit throw new Promise.CancellationError() "fixes" the problem. What I don't understand is why?
Why was the original approach not working?
I am using bluebird 2.3.11.

cancellable() creates cancellable promises and only they throw CancellationError by default, when cancel function is called with out any reason.
In your case, you are making the promise cancellable only after attaching the catch handler. But the promise is not cancellable yet. So, cancel function call will not raise Promise.CancellationError.
You need to change the structure of the code, like this
then(function(..) {
...
})
.cancellable()
.catch(Promise.CancellationError, function (err) {
...
});
Note: I would recommend promising with its beautiful Promise constructor function. It is similar to the ECMA Script 6 specification.
new Promise(function(resolve, reject) {
...
});