Your code crashes my browser and locks my system, so without digging into it too much I can just say you’ve definitely created an infinite loop. I console logged j and for [1,13], j goes 2,3,4,5,6,7,8,9,10,11,12,13 over and over and over until the system runs out of memory, adding 1 to answer every time it goes past 13. Challenge is not bugged btw

I know the challenged is not bugged, and I know that there is some issue with my code (but its definitely not an infinite loop). I just can’t understand where I am going wrong and why the browser’s console and repl.it are showing different behaviours.

You do not have an infinite loop, but FCC’s test suite thinks you do, because your code takes longer than it expects. When this happens, the infinite loop protection feature kicks in and stops the “slow” code from continuing.

To resolve this issue, you must use a more efficient algorithm which is faster and does not cause the infinite loop protection to kick in. All of the FCC challenges can be solved with algorithms which are efficient enough to prevent the infinite loop protection from activating. Think how you could modify your current algorithm to achieve faster results.

Yea I get that, but the infinite loop protection standard in-browser kicks in and it then breaks my system; I didn’t check if it was actually an infinite loop, just assumed so, so apologies for that. It’s just horribly inneficient, as @RandellDawson says. It works in replit because replit evals whatever you put & executes that using Node, not the browser, whereas browsers have more stringent memory allowances