Closed jrainville closed 5 days ago
:grey_question: | Commit | :hash: | Finished (UTC) | Duration | Platform | Result |
---|---|---|---|---|---|---|
:heavy_check_mark: | cb61418dd9d517ba118d80fac19f7d7dc0c4715d | #3 | 2024-06-25 17:30:50 | ~2 min | android |
:package:aar |
:heavy_check_mark: | cb61418dd9d517ba118d80fac19f7d7dc0c4715d | #3 | 2024-06-25 17:31:01 | ~2 min | linux |
:package:zip |
:heavy_check_mark: | cb61418dd9d517ba118d80fac19f7d7dc0c4715d | #3 | 2024-06-25 17:31:58 | ~3 min | ios |
:package:zip |
:heavy_check_mark: | cb61418d | #3 | 2024-06-25 18:11:25 | ~42 min | tests |
:page_facing_up:log |
Fixes https://github.com/status-im/status-desktop/issues/15175
The problem was that we used StartMembersReevaluaitonLoop in createCommunityPermission, in case the loop was never started. Indeed it worked if it was the first ever permission, because the loop would then start and members would be re-evaluated.
However, if the loop was already started, in the case where there were previous permissions, the call would just early exit, because it was already started.
The solution here is to use
ScheduleMembersReevaluaiton
like other permission functions use. To make sure a first permission still works, we call startLoop in schedule if the task doesn't exist.You can see the fixed behavior here (sorry for the long wait, I changed the reeval delay to be 1 minute instead of 5, but it's still something)
reeval-on-create.webm