The former updates how recipients (or really threads, I suppose) are merged (the issue occurred when trimming threads) and the latter changes the way how thread ids are generated (now automatically incremented). Together they should prevent unrelated recipients (threads) from being merged.
Using incrementing ids as your source of ownership is just asking for trouble. This just means a programming error can have a high probability of ids lining up and leaking resources. Guids make this practically impossible.
I wonder if there's any widely implemented programming pattern that would catch this better, eg consisting of concatenated type code and id. Using GUIDs here would still hide the bug, not flag an error.
If I understand the issue [0] correctly, these two commits should be the fix:
https://github.com/signalapp/Signal-Android/commit/e90fa05d6...
https://github.com/signalapp/Signal-Android/commit/b9657208f...
The former updates how recipients (or really threads, I suppose) are merged (the issue occurred when trimming threads) and the latter changes the way how thread ids are generated (now automatically incremented). Together they should prevent unrelated recipients (threads) from being merged.
[0]: https://github.com/signalapp/Signal-Android/issues/10247#iss...