can any one suggest me beginner level async problems!

If not, the kata should create scenarios where this isn't the case, in order to invalidate solutions that can't handle this.

reminds me of a manager I had. no matter the task, always ended it with "Should be easy".

Instructions are unclear and vague:

"magic_ - a special property as it should be able to handle numbers given with it" should write "magic_ - special instance
and its property is being able to handle numbers given with it"and since it has and underline its not a public but private instance.
"whereami" is also instance and "whoami" is also instance.

<func>.callback should also have an optional parameter n which decides in which order a callback function is invoked. n is completly relative to its anchor and not necessarily to root. If n == 0 its called first, if n == 1 its called secondly and so on. If n > number of callbacks then the callback is appended to the end of the callchain of its anchor.

How does inserting multiple callbacks with different ns work? Depending on the meaning of n it can mean one of these things:

• n is the priority of the callback; callbacks are order by n, then register order. This means using callback(1) after many callback(0) will not affect the ones registered with callback(0)
• n is the order of the callback stack at the moment; callbacks are treated as a list that can be inserted anywhere. This means using callback(1) after many callback(0) will push all registered callback(0) callbacks except the last registered one after this callback

In the current design it implies the latter (from the default value being n, and n called at number of callbacks), but this design is unhinged and absolutely nightmarish to use.

Also, note that the test only tests a single use of n = 0, so it doesn't touch any of the scenario above, and both implementations will pass. This needs to be explicitly tested.

Random tests have fixed structures with randomized arguments, which is not acceptable. It is very easy to hard code against this (especially since it is the same structure as the sample tests).

So now, when the root function is invoked, it passes its result to foo which then passes its result to eggs

root |> foo |> eggs

The semantics of result passing and arity handling is not defined anywhere. Apparently root can be in any arity, while every callback function must have arity 1 (and every returned result is directly passed to the next function). Having different handling for root and branch nodes is certainly not expected (also technically you can pass around multiple arguments by spreading an array, like in JS), and should be specified.

Pretty neat kata, a bit challenging, I would say. I do believe it deserves 4 kyu for asynchronous stuff, but maybe 6-5 kyu can be enough.

Anyway, +1 to karma, hope this will be approved ^.^

To be honest, the description could have been much clearer (I fixed it after solving). I ran into the same problem too.

I don't think it's a general issue, Pavloslav! It'd fit into the suggestion category though in my opinion. 😊

By the way, 1 result was the expected lookup count, most probably because the kata was in beta (I approved this morning after fixing issues). Once approved, the kata is more likely to be put into the "similar kata" as you said.

The description claims that

intext:"google dorking" site:codewars.com

gives exactly 1 result, but it gives 2 to me and will be more because some pages have "SIMILAR KATA:" section.

Not a great issue, but still...

.

Patched kata descriptions so that this criteria can be easily understood, code has no problems.

Description for which filters are valid is missing (as Voile mentioned) and has not been fixed in JavaScript. At least you should provide a preloaded array of allowed filters.