Unit test select_outputs.exact_unlock_block failing

[ComputeryPony]

It's been sporadically failing in CI for a while.
After poking at the test a bit, it seems like it will always fail when the crypto::rand<size_t>() & 0x1f call in the MKOFFSETS macro returns 0.
Resulting in MKOFFSETS(300000, 1); being used in the setup of the test.

Unfortunately I don't have any knowledge of how the gamma_picker should be behaving to know if this is a broken unit test or a edge case not being handled in the gamma_picker.

I can see that the MKOFFSETS call with just 1 specified makes offsets just go from 1 to N smoothly.
The test seems to want to make sure the gamma_picker can always pick the calculated exact_block_offsets_start_inclusive (299990 in this case).
However, there seems to be an off by one somewhere as the gamma_picked repeatedly picks up to 299989 but never picks 299990.
Again I can't tell if this is in the gamma_picker or in the unit test's calculation of the "correct" exact_block_offsets_start_inclusive.

If someone more knowledgeable could take a look, it would be nice to not have it sporadically failing. (And make sure it's not actually a bug in the gamma_picker)

[selsta]

See #8024

It needs a review and I'm not sure if @j-berman still thinks this patch is the best solution here.

[ComputeryPony]

Ah, of course I searched the bug tracker for "exact_unlock_block" but not with spaces, so I didn't find the issue. Thanks for pointing out the duplicate.
Should I leave this issue open or close it?

[selsta]

Seems you mentioned a different test failing, I'm not sure if the PR I linked is relevant here.

[ComputeryPony]

Yeah, that actually does look like a different set of issues, I don't see the exact_unlock_block test mentioned anywhere in there.

EDIT: This would make sense since the exact_unlock_block test didn't exist at the time, it was introduced in eb0e405 and hasn't been touched since.