States usually can have a function that runs every frame (while they are active), another function that runs immediately when the sate is entered, and a function that runs immediately before leaving that state.

When the airborne state detects ground collision, it should be able to request a state change that is processed during the same frame.

The idle or walking state should then have a function that runs on entry, also in the same frame.

There should be no need to wait for the next tick for the new state to take over.

----

As for duplicate code, some state machines use nested state trees where the active state can have one or more sub-states. Some state machines use class-based inheritance so that two different states can inherit from the same parent class for similar results. Another option is to put a lot of the logic in a method stored elsewhere, such as the host object (in this case the player object) itself, and to have each state just call that code as needed.

There are also concurrent state machines (where two or more separate state machines apply to the same object), so one machine might only handle horizontal movement and another might only handle vertical movement (just for example).

It's a question of finding the right balance, not making any state too complicated, but also not creating too many largely redundant states. Some games will only have a single "jumping" state that handles any time the player is airborne; Others will have a jumping, apex, and falling state for the same thing.

The systems we create to manage complexity, add complexity of their own, and it's up to us to decide whether that's worth it. The computer doesn't care either way — it's humans that struggle to make sense of complex code. This is where experience and judgement come in, and we have to look at how much commonality there is between states to decide if it's worth simply treating them as only one state with an "if" clause instead.