You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The automatically generated ids are 128-bit, but the PRNG's seed is only 32-bits. If clients only commit one transaction per process/network thread, then each transaction's id should be fully determined by the 32-bit seed. According to the birthday problem we only need about 82137 transactions in the unexpired window of idempotency ids until we expect to see a collision.
I haven't tried to reproduce this yet, but I expect an effective mitigation to be setting the hidden idempotency_id option with sufficient entropy prior to setting the automatic_idempotency option.
There may be other places we can run into UID collisions because of 32-bit seeds. I don't know if using 128-bit seeds is sufficient to mitigate all this, but it would definitely be better.
The text was updated successfully, but these errors were encountered:
The automatically generated ids are 128-bit, but the PRNG's seed is only 32-bits. If clients only commit one transaction per process/network thread, then each transaction's id should be fully determined by the 32-bit seed. According to the birthday problem we only need about 82137 transactions in the unexpired window of idempotency ids until we expect to see a collision.
I haven't tried to reproduce this yet, but I expect an effective mitigation to be setting the hidden idempotency_id option with sufficient entropy prior to setting the automatic_idempotency option.
There may be other places we can run into UID collisions because of 32-bit seeds. I don't know if using 128-bit seeds is sufficient to mitigate all this, but it would definitely be better.
The text was updated successfully, but these errors were encountered: