"wait for input" event causes freeze when clicked too quickly

[MyChemicalAddiction]

The problem

Describe the bug
When I start a timeline that has a 'wait for input' event preceded by a text event, and advance the dialogue after the text event really quickly (before the text event finishes fading out) it works fine. However, if I try to start the same timeline again, it does not work, and shows a dialog box quickly appearing then disappearing, then freezes the game.

To Reproduce
First, start a godot project and install dialogic as an addon.

Make any timeline that has a 'wait for input' event at the end of it.
For example:

text
[wait_input]

Then, create a simple 2d or 3d scene, with the script:

func _physics_process(delta):
	if Input.is_action_just_released("start_dialog"): # Add this in the input map
                Dialogic.start('timeline') # Assuming the timeline you created is named 'timeline'

Now, start the timeline, and click through the dialog really quickly, until it ends. After it ends, start it again. A dialog box should quickly appear then fade, and the game should freeze.

Expected behavior
For timelines containing 'wait for input' events to start successfully, no matter how quickly the previous timeline was clicked.

System (please complete the following information):

• OS: Windows 10
• Godot Version: 4.2
• Dialogic Version: 2.0 - alpha 14

Screenshots
Here is a video of the bug:
https://github.com/dialogic-godot/dialogic/assets/60291234/cc278b61-88fc-4306-810f-e7e276570415

Solutions

Workaround

What works is adding a wait time before the player can get past the wait_input event. The time should be long enough so that the animation of the text disappearing ends Before the player can click to get past the wait_input event. Meaning, changing the timeline example I gave above to:

Text
[wait time="1.0"]
[wait_input]

Where, the player will:
-click once to get past the Text
-wait 1 second, after which the animation for the text disappearing ends completely
-click again, to get past the wait_input event
and no bug will be caused.

Note: I know that this is not the way a wait_input event is conventionally used, and that it makes no sense to add it here. But, in other cases where it does, the bug still occurs.

[Jowan-Spooner]

I can recreate this. I will look into it now.