Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MXCallManager: Make call transfer requests sequential #1739

Merged
merged 1 commit into from
Mar 14, 2023

Conversation

manuroe
Copy link
Contributor

@manuroe manuroe commented Mar 14, 2023

Make sure we made requests one by one to avoid to create weird scenarii.

@manuroe manuroe force-pushed the manu/call_transfer_requests_order branch from 93c9854 to c6aa99e Compare March 14, 2023 10:26
@manuroe manuroe requested review from a team and alfogrillo and removed request for a team March 14, 2023 10:26
@codecov
Copy link

codecov bot commented Mar 14, 2023

Codecov Report

Patch coverage has no change and project coverage change: +19.83 🎉

Comparison is base (b63e064) 17.67% compared to head (c6aa99e) 37.51%.

Additional details and impacted files
@@             Coverage Diff              @@
##           develop    #1739       +/-   ##
============================================
+ Coverage    17.67%   37.51%   +19.83%     
============================================
  Files          612      612               
  Lines        96547    96554        +7     
  Branches     40518    41731     +1213     
============================================
+ Hits         17066    36220    +19154     
+ Misses       78968    59285    -19683     
- Partials       513     1049      +536     
Impacted Files Coverage Δ
MatrixSDK/VoIP/MXCallManager.m 0.40% <0.00%> (-0.01%) ⬇️

... and 196 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[callWithTarget transferToRoom:nil
user:transferee
createCall:nil
awaitCall:newCallId
success:^(NSString * _Nonnull eventId) {
dispatch_group_leave(dispatchGroupReplaces);
dispatch_group_leave(dispatchGroup);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you also need to leave the dispatch group in case of failure

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We definitely do not want to make the next request if the first one failed.
Does it create an issue (like a retain cycle) if we let the dispatch_group open?

The code before was worse. It could generate 2 calls of the failure callback without "releasing" the dispatch group.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it create an issue (like a retain cycle) if we let the dispatch_group open

This is what I meant.
A dispatch group with a work count equal to "one" will stick somewhere forever I guess.
But I can't find easily a confirmation of this (DispatchGroup objects don't work as normal ARC objects).
Btw I don't see it as a huge problem, I'm going to approve it anyway.

[callWithTarget transferToRoom:transferRoom.roomId
user:transferee
createCall:nil
awaitCall:newCallId
success:^(NSString * _Nonnull eventId) {
dispatch_group_leave(dispatchGroupReplaces);
dispatch_group_leave(dispatchGroup);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same problem here

@manuroe manuroe merged commit 0d2d53e into develop Mar 14, 2023
@manuroe manuroe deleted the manu/call_transfer_requests_order branch March 14, 2023 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants