then warning creates messy logs for thenable APIs

[bendrucker]

The recent addition of warnings when then is called with a non function argument is creating messy test output over at Knex. The basic issue here is that query objects are thenables that proxy to a real promise which gets created. Since Promise.longStackTraces turns on debugging, we're getting loads of warnings about empty thens in the integration tests.

The easy fix here is just to revert the warning, but I understand if there was a compelling reason to do it. We could also use promise.then.apply(promise, arguments) in place of explicitly passing the two callbacks to promise.then. I'd prefer not to go that route since it's harder to read/understand.

[myndzi]

I don't see how this is a bluebird problem in any way. The warning is justified, and knex is doing weird things it shouldn't. The fix is to stop doing weird things, not to complain to bluebird to remove the warnings. I've NEVER had good results trying to wrap or fiddle with the "then" method of a promise, or providing a pretend/pseudo promise by providing a then method. I don't understand what knex is trying to do well enough to suggest a viable alternative, but I can see that it's doing something that will only cause pain.

Edit: possibly the hooks patch may provide a viable alternative to "doing something after the query"

[benjamingr]

@myndzi I totally see why this is our problem. We have every obligation not to break backwards compatibility and I'm against any reasoning that blames the users of the library for a breaking change.

When we introduced the warnings we could not come up with reasonable workflow issues (We considered cloning a promise).

@bendrucker there will be a hook that allows you to opt-out of these warnings (but it's planned for 3.0 for better debuggability). I'm afraid it's not there yet - I wonder if it can be backported to 2.9.*

In the interim I suggest a revert in 2.9.x - what do you think @petkaantonov ?

[benjamingr]

@bendrucker why would you .then() a transaction or a target() without arguments?

[myndzi]

It's not a breaking change though?

The code is apparently calling .then() to get an instance of a promise derived from the source (where the '.then' method had been replaced); it seems to want to execute some code before executing the .then handler, but it doesn't want to execute that code until the .then method is called, thus the whole wrapping thing.

[bendrucker]

@benjamingr A hook sounds perfect. There are a number of cases where you might end up calling then without arguments. One is if you want to get at a Bluebird helper method that's not proxied, e.g. query.then().get(0). Another would be returning inside a promise:

promise.then(function () {
  return query;
});

So query.then is implicitly called with no arguments in that case. This totally goes away when applying arguments from the thenable's then to the actual promises's then instead of manually passing them.

In general I'm of the opinion that warnings should always be opt-in and libraries should throw when something's wrong and never write to the console. So in this case my ideal solution (not Knex's, but the one that fits best with how I write things) would be to change the philosophy around warnings. A user could opt in, a la strict mode, to have Bluebird throw in cases like this.

[bendrucker]

Also this is purely a cosmetic issue right now with the test logs. It's not going to affect users of Knex.

[petkaantonov]

@bendrucker You could just call ._then? It's forced to retain same api signature across all versions, even major.

btw In 3.0 warnings are disabled/enabled with

Promise.config({
     warnings: false,
     longStackTraces: true
});

Note that .then() doesn't cause a warning, in fact it's used internally many times. Warning is only given when you explicitly pass value(s) that are all non-functions.

[bendrucker]

If you're considering reverting and saving for 3.0 I'll wait on that. Otherwise I'll drop in a fix and probably just end up applying the arguments.

[benjamingr]

@bendrucker note that you did opt into the debug build when you enabled long stack traces. Like petka said in v3 we'll have finer grained control.

I'm for reverting this and introducing it in a major for breaking workflows.

[benjamingr]

@petkaantonov any update on reverting this in 2.x? There has been a release since the issue opened and I want to know if you decided one way or the other.

[petkaantonov]

Well I don't see any reason to revert this, the fix is simple for knex and people will use 2.x for a while.

[bendrucker]

Fair enough. I've fixed it in knex.