the failed event must first go to a new state with a "next frame" action in it. This action is like the wait action, but it only waits one frame.
Without that next frame action it would go like :
Compare Int = false -> send FAILED event
FAILED event goes back to the same state. Then Playmaker runs the first action of the state which is
Compare Int = false -> send FAILED event
and of course the failed event still goes to the same state.
Since this would go on like this forever, it is called an infinite loop.
Often infinite loops are what you want. You may want an object to move each frame for example. That too would be an infinite loop.
The problem here is though that your infinite loop is running infinite times per frame, not once like the good ones do.
This is because PlayMaker runs stuff as fast as possible. In this example it checks the statement as soon as the FSM is loaded, sees that it's false, and then checks it again right when the previous statement returned false. Since time in games is based on frames, and your current frame is infinitely long because it loops your state forever, the statement will never even have the chance to turn true.
Now, the next frame action fixes this. With it you first check the statement, if it returns false , it will wait until everything else is done calculating (=> until the next frame starts), and then it will try loop back to the statement and check it again. Since it's a new frame, the statement may now return true.
But even if it never turns true, this way you will at max only check it 60 times per second. And that's quite nothing for a processor.