Gateway with embedded network requester crashes with "Tried to insert duplicate pending ack" about nym HOT 4 CLOSED

Does downgrading the panic to an error log not only kick the problem down the road? What if subsequently the entry with id frag_id is requested from self.pending_acks_data in order to update or remove it, and now multiple items with identifier frag_id exist?

Given the small range [1, 2147483647] from which set_ids are randomly chosen, would it not make sense to increase set_id from i32 (with excluded edge cases) to i64 (with excluded edge cases)? This way, at least the probability of generating a set_id collision is much reduced.

Yep that's correct. Well at least things like this shouldn't take the whole gateway down now, which is critical, but yeah there is a small small % of packets that are corrupted by this.

And also yes I agree it would be good to increase the id to 64-bit, the challenge is doing that gradually without breaking things on mainnet. So it's a little more than just changing the type

from nym.

Is this issue still present? At least it shouldn't panic since #4248. Although it's a bit of a mystery why this even happens in the first place ...

from nym.

Closing the ticket based upon @octol comments

from nym.

Does downgrading the panic to an error log not only kick the problem down the road? What if subsequently the entry with id frag_id is requested from self.pending_acks_data in order to update or remove it, and now multiple items with identifier frag_id exist?

Given the small range [1, 2147483647] from which set_ids are randomly chosen, would it not make sense to increase set_id from i32 (with excluded edge cases) to i64 (with excluded edge cases)? This way, at least the probability of generating a set_id collision is much reduced.

from nym.