Amount of information in this bug report makes it impossible to even start fixing the issue. Closing as per insufficient details.

There are two problems with your solution:

• For n = 30, 30! has 32 digits but JavaScript's Number can hold ~16 digits at most. When your values get larger than 16 digits, the least significant digits are lost and you cannot use them reliably for this problem.
• In this kata, n can go up to 1_000_000_000. Calculating 1_000_000_000! will take forever, and your naive solution will not work because it will be too slow, and will eat up whole available memory.

You need to find some better approach than calculating the exact value of the factorial.

Your solution seems to work fine for me, and the network error sounds unusual. Can you submit solutions to any other kata? Can you submit your solution to this kata again in a couple of minutes?

It is sometimes a vowel, and mostly a consonant.

Trying to not look through the keyhole of one specific language, a serious, honest question: out of all distinct languages which recognize the letter Y, how many of them considers it as a vowel, how many as a consonant, and how many as "it depends"? Has anyone any idea here?

I can guarantee you that every Polish person gets utterly confused when Y is not considered a vowel in a kata. For such user, Y is a vowel, always, period.

I also dont understand what exactly is the problem here. Y being a vowel or not is ambiguous and not well defined in general. Task clearly, unambiguously specifies this, comforming to one of possible, well known interpretations. What is the problem then?

Why do you think something is wrong with the kata, and not with your solution?

Yes, you are missing something.

Please check my fork. The issue of many tests expecting 0 is because the available ingredients are not guaranteed to include the ingredients from the recipe. This seems to be the case in Python and maybe other languages as well. Anyway, I did fix it by making sure that half the time the available ingredients include a random sample from the recipe. "half the time" can be easily modified to be any other desired fraction.

You need to fix your solution.

• limits.h should be climits
• common includes should not be included via Preloaded snippt, they should be present in every snippet which needs them
• Sample tests, Assert::That(actual, Equals(exp), "example #1"); - custom messages do not work this way. They should be provided with ExtraMessage (see here) or similar message supplier. Interesting fact, random tests got this right :) They are also not really necessary in example tests, maybe just remove them.
• Randomly generated tests could be balanced a bit better. Currently, ~40 out of 50 random tests expect 0.

Yes, it's a known bug. I think I was able to make your solution visible, please check.

This is not a proper way to report a bug in a kata.

If you want to report a bug, you need to:

• Tell what language you are attempting,
• Show your formatted code,
• Show what input causes problems, and why you think it's not handled by tests correctly.

Your solution not passing tests is not a kata issue.

Your PHP function doesn't account for all possible game outcomes, specifically the cases where "rock" and "paper" are played against each other. Since your function doesn't return anything for those cases, it returns null by default, which leads to the failed test cases. To fix this issue, you need to add conditions to handle the missing game outcomes: when "rock" plays against "paper" and vice versa. Make sure your function returns a result for every possible combination of inputs it might receive, ensuring it never unintentionally returns null.

Your solution has a bug, it's not a kata issue.

altered in fork

This paragraph explains this.