Why is [counter] sending a bang to [random] twice instead of once?

Generate number 0 to 255
Is that number bigger or smaller than the previous number?
If bigger, set the new number as the maximum on [counter].
If smaller, set the new number as the minimum.
Count from current number until you reach either the maximum or the minimum, which ever has been newly set.
Repeat

This is what the patch is supposed to do and it's close. The problem is that [random] is triggered twice for every new evaluation process and I don't want it to do that. Most of the time this happens to not be a problem. But, for instance:

(there should only be new #1)
If new #1 < new #2 and if new #1 set the direction to downwards &&& if the current counter value is lower than both of them, then the counter value jumps up to new #2, then counts down to #1.

I just don't know why [random] is receiving two bangs and I'm pretty sure that's the problem. Thanks for any help! Maybe a look at just the patch will reveal why (am a beginner. Big chance this is simple).

Else here's my attempt at explaining how the patch works with some console feed at the bottom.

~~~~~Too much explanation~~~~~

The minimum value is set to 3.
[counter] outputs 5, 4, then 3.
The minimum value is hit so the underflow flag outlet sends a 1 to [random] up top.

First, [print new] prints the result first. Then, the result goes to [prepend set] and then two integer boxes.

Here's where it gets a little hard to follow:
Then the [random] result is sent to [<] and it's compared to the previously randomly generated number. This is to determine what direction the counter should now count, up or down. ({print})

If it's a 0 (the new number is greater than), then [sel 0 1] sends a bang which sends the result stored in the integer box to (another [print] and then) the right inlet on the counter. And the result is set as the new maximum.

If it's a 1 (the new number is less than), then [sel 0 1] sends a bang which sends the result stored in the other integer box to [prepend setmin]. This is sent to the left inlet on [counter] where it sets the new minimum value.

So in this case, the minimum value is reached and that bang triggers the evaluation process. 119 is the new number, great. 119 > 3 so direction is to 0 so it's going to count up from 3 to 119, fantastic.

CONCERN: But then [random] generates a new number. Why? Most of the time this happens to be fine. If it generates another number larger than 3, then that's just set to be the maximum value and the process continues.

But here the new number is 26. 26 < 119 so the direction is changed to downwards and the minimum is set to 26.

On the next bang from the metronome, the counter is set to the new maximum, I think because the direction is now downwards. And I know this makes sense for the [counter] object.

But I feel like this shouldn't be an issue if [random] weren't to be triggered again(?)

(Not sure what "curdir" means and how it's distinct from "direction")

counter: -=% CounterState %=-
counter: x_mincount : 3
counter: x_maxcount : 142
counter: x_direction : 1
counter: x_curcount : 5
counter: x_curdir : 1
([metro)) [bang]
counter: -=% CounterState %=-
counter: x_mincount : 3
counter: x_maxcount : 142
counter: x_direction : 1
counter: x_curcount : 4
counter: x_curdir : 1
[bang]
minsend: 1
new: 119
direction: 0
print: setmax 119
counter: -=% CounterState %=-
counter: x_mincount : 3
counter: x_maxcount : 119
counter: x_direction : 0
counter: x_curcount : 3
counter: x_curdir : 0
[bang](??)
minsend: 0
new: 26
direction: 1
print: setmin 26
counter: -=% CounterState %=-
counter: x_mincount : 26
counter: x_maxcount : 119
counter: x_direction : 1
counter: x_curcount : 4 (and then jumps to 119)
counter: x_curdir : 1
[bang]
counter: -=% CounterState %=-
counter: x_mincount : 26
counter: x_maxcount : 119
counter: x_direction : 1
counter: x_curcount : 119
counter: x_curdir : 1
[bang]
counter: -=% CounterState %=-
counter: x_mincount : 26
counter: x_maxcount : 119
counter: x_direction : 1
counter: x_curcount : 118
counter: x_curdir : 1