9 ms·
> Can you provide a link to the commit that fixes it? If I understand the issue [0] correctly, these two commits should be the fix: https://github.com/signala
by tomudding 5y ago
> Can you provide a link to the commit that fixes it?
If I understand the issue [0] correctly, these two commits should be the fix:
https://github.com/signalapp/Signal-Android/commit/e90fa05d608d49759e4cbac8cf233a797e0ee395 https://github.com/signalapp/Signal-Android/commit/e90fa05d6...
https://github.com/signalapp/Signal-Android/commit/b9657208fea1c7bcfb90b7400037a7858ba56516 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#issuecomment-886239978 https://github.com/signalapp/Signal-Android/issues/10247#iss...
- deleted 5y ago[deleted]
- winrid 5y agoI love the terrible commit name. "Updating recipient merging."
- hackinthebochs 5y agoUsing 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.
- rattray 5y agoInteresting, I hadn't thought of that advantage of uuids/guids before.
- fulafel 5y agoI 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.
- ultrarunner 5y agoI don’t know if it’s widely implemented, but the way Stripe IDs resources comes to mind.