bug(ffi): Creating a proposal every millisecond will fail after 50 days #1272
Description
Seems like we can create proposals faster than that, and the proposal_id is supposed to be guaranteed never to be zero, but this isn't checked anywhere, so we will eventually cause an overflow.
If you can pull off creating one every microsecond, you could overflow in less than 2 hours.
AtomicU32::fetch_add is documented to use wrapping add semantics.
There are two possible fixes:
- Switch ProposalId to use AtomicU64 (this would be a breaking API change); or
- Check for zero and allow for wrapping around to 1. In this case, we should consider checking for an existing proposal ID and skipping those.