Synchronous tasks without callback don't finish
miguel-leon opened this issue · 8 comments
In line 55 function taskFunction (callback) { ... } defines a parameter (callback) that conflicts with orchestrator's runTask which relies in Function.length and interprets that the task terminates only after the callback is called.
In this sense, the config argument passCallback lacks purpose and the tasks written in separate files are obliged to function with a callback parameter or they won't finish.
Hello @miguel-leon! After a thorough investigation I can see the problem is with synchronous task functions only. It's pretty rare use case in my opinion, cause probably most gulp plugins return proper streams and most of the node modules are also asynchronous in nature.
Could you elaborate please, what is your use case with synchronous task functions?
Also, what solution are you seeing to this problem?
Thank you!
Hello @slavafomin, I was about to write. You're right, I didn't realize it didn't happen with (most commonly used) tasks that return promises or streams.
It is produced with tasks that do something synchronous like logging.
I should have realized it and specified which kind of tasks are the ones not finishing.
I guess, it's a little bit cumbersome to fix since orchestrator is relying in Function.length in the first place.
Maybe having two functions function taskFunction (callback) { ... } and function taskFunction () { ... }. But it might just not worth the trouble for the uncommon use case.
Should I edit the posts and specify what type of tasks are not finishing or should they be closed.
I think I will just add a warning and an example to the documentation regarding synchronous task functions. The workaround is pretty simple: either fire a callback from your synchronous functions or just use a nativeTask functionality. I think it's a very rare situation and it's a pretty low price to pay for splitting tasks across separate files.
@miguel-leon I've updated the README to specifically address this use case. Feel free to use one of the described workarounds. Thank you for pinpointing this problem.
Cheers!
I will leave this issue open for now. Maybe in the future we will find a way to make it work transparently to the end user. Do a thumbs up if you think this feature is necessary.
Hi @slavafomin, I concur it is the best thing to do by now. I had already used and confirmed both workarounds.
The only thing to notice, is that, for now, there is no purpose in setting passCallback to false, as it's the last argument, it may just stay true and omit the function parameter when not needed.
Thanks for taking the time.
Cheers...
there is no purpose in setting passCallback to false, as it's the last argument
It's a matter of taste, I just wanted to give the end user the most possible control of the task function.
Maybe someone is doing something nasty with arguments and this functionality is needed.
I'm going to close this now.