-
Notifications
You must be signed in to change notification settings - Fork 15
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
fix: crash calleventstatus - WPB-10449 #2233
base: develop
Are you sure you want to change the base?
Conversation
@@ -1037,12 +1037,13 @@ extension ZMUserSession: ZMSyncStateDelegate { | |||
WireLogger.updateEvent.info("process pending call events") | |||
Task { | |||
do { | |||
// why not processing only the call events (should be stored here?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question maybe to @johnxnguyen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is an optim that could be done in another PR, to directly process callEvents instead of buffered ones. I don't see why we would need to process all events in a method processPendingCallEvents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why it does this... but it does more than just process events, it also decrypts and stores first the buffered events that may have be received in the push channel. If you were going to optimize this, you need to decrypt and store the buffered events, and then process only the stored calling events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added to a ticket for it
@@ -182,7 +182,8 @@ public final class VoIPPushManager: NSObject, PKPushRegistryDelegate { | |||
payload: [AnyHashable: Any], | |||
completion: @escaping () -> Void | |||
) { | |||
Self.logger.trace("process voIP push, payload: \(payload)") | |||
// TODO: check this is dead code right? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from my understanding this is never used, we always use the APNS code, is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The device will only receive APNS pushes and wake the NSE, but the NSE can create a "fake voip push" when it detects a call event and pass it to the main app.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the point of view of the app, it looks like a real VoIP push, but in reality it came from the NSE. So we need this code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@samwyndham you're referring to this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that is what I'm referring to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was mistaken here which we clarified in a call a while ago.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @samwyndham
Test Results 3 files 3 suites 2m 21s ⏱️ For more details on these failures, see this check. Results for commit a921213. ♻️ This comment has been updated with latest results. |
db256ac
to
b1b0aed
Compare
bf0e86f
to
febbcf2
Compare
wire-ios-sync-engine/Source/Synchronization/ZMOperatonLoop+Background.swift
Show resolved
Hide resolved
wire-ios-sync-engine/Source/Synchronization/Strategies/CallingRequestStrategy.swift
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a first pass and looks good but I guess we need to resolve @johnxnguyens points first and maybe add back some of the code that was removed?
@@ -1037,12 +1037,13 @@ extension ZMUserSession: ZMSyncStateDelegate { | |||
WireLogger.updateEvent.info("process pending call events") | |||
Task { | |||
do { | |||
// why not processing only the call events (should be stored here?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why it does this... but it does more than just process events, it also decrypts and stores first the buffered events that may have be received in the push channel. If you were going to optimize this, you need to decrypt and store the buffered events, and then process only the stored calling events.
Datadog ReportBranch report: ✅ 0 Failed, 2014 Passed, 2 Skipped, 2m 6.69s Total Time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work 🛁!
Issue
There is a crash (see ticket) involving CallEventStatus that happens from time to time. Looking at the usage of CallEventStatus, it appears we don't really need this at all. This PR cleans up unused code in order to resolve the crash.
Testing
Checklist
[WPB-XXX]
.