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

fix: crash calleventstatus - WPB-10449 #2233

Open
wants to merge 15 commits into
base: develop
Choose a base branch
from

Conversation

netbe
Copy link
Collaborator

@netbe netbe commented Dec 2, 2024

BugWPB-10449 Crash on ZMTimer - CallEventStatus

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

  • running app and check for regression

Checklist

  • Title contains a reference JIRA issue number like [WPB-XXX].
  • Description is filled and free of optional paragraphs.
  • Adds/updates automated tests.

@netbe netbe self-assigned this Dec 2, 2024
@netbe netbe marked this pull request as draft December 2, 2024 14:50
@@ -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?)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

question maybe to @johnxnguyen

Copy link
Collaborator Author

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

Copy link
Collaborator

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.

Copy link
Collaborator Author

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?
Copy link
Collaborator Author

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?

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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?

Copy link
Contributor

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

Copy link
Collaborator

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Copy link
Contributor

github-actions bot commented Dec 2, 2024

Test Results

    3 files      3 suites   2m 21s ⏱️
2 051 tests 2 048 ✅ 2 💤 1 ❌
2 051 runs  2 049 ✅ 2 💤 0 ❌

For more details on these failures, see this check.

Results for commit a921213.

♻️ This comment has been updated with latest results.

@netbe netbe changed the title WIP - fix crash calleventstatus fix: crash calleventstatus - WPB-10449 Dec 20, 2024
@echoes-hq echoes-hq bot added the echoes: unplanned Any work item that isn’t part of the product or technical roadmap. label Dec 20, 2024
@netbe netbe changed the base branch from release/cycle-3.114 to release/cycle-3.115 December 20, 2024 08:43
@echoes-hq echoes-hq bot added echoes: unplanned/quick-win Work items completed to address issues quickly, without extensive planning. echoes: technical-roadmap/throughput More specific category, to highlight task aiming at improving the development velocity and effici... echoes: technical-roadmap/security More specific category, to highlight task that tackle security requirements. echoes: product-roadmap Work aligned with the customer-announced roadmap, targeting a specific release date. echoes: technical-roadmap Work contributing to the Technical Roadmap, to improve our velocity or reduce the technical debt. echoes: technical-roadmap/technical-debt More specific category, to highlight Technical Debt being tackled. echoes: product-roadmap/bug Work contributing to resolve a bug not critical enough to have raised an incident. labels Dec 20, 2024
@netbe netbe changed the base branch from release/cycle-3.115 to develop December 20, 2024 08:44
@netbe netbe force-pushed the fix/crash-calleventstatus branch from db256ac to b1b0aed Compare December 20, 2024 15:12
@netbe netbe force-pushed the fix/crash-calleventstatus branch from bf0e86f to febbcf2 Compare January 9, 2025 13:59
@netbe netbe marked this pull request as ready for review January 9, 2025 14:07
@netbe netbe requested review from a team, samwyndham, caldrian and KaterinaWire and removed request for a team January 9, 2025 14:07
Copy link
Contributor

@samwyndham samwyndham left a 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?

@netbe netbe requested a review from johnxnguyen January 13, 2025 15:39
@@ -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?)
Copy link
Collaborator

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.

@netbe netbe requested a review from samwyndham January 14, 2025 15:37
@netbe netbe enabled auto-merge January 14, 2025 15:38
@datadog-wireapp
Copy link

datadog-wireapp bot commented Jan 15, 2025

Datadog Report

Branch report: fix/crash-calleventstatus
Commit report: 5e8be44
Test service: wire-ios-mono

✅ 0 Failed, 2014 Passed, 2 Skipped, 2m 6.69s Total Time

Copy link
Contributor

@samwyndham samwyndham left a comment

Choose a reason for hiding this comment

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

Nice work 🛁!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
echoes: product-roadmap/bug Work contributing to resolve a bug not critical enough to have raised an incident. echoes: product-roadmap Work aligned with the customer-announced roadmap, targeting a specific release date. echoes: technical-roadmap/security More specific category, to highlight task that tackle security requirements. echoes: technical-roadmap/technical-debt More specific category, to highlight Technical Debt being tackled. echoes: technical-roadmap/throughput More specific category, to highlight task aiming at improving the development velocity and effici... echoes: technical-roadmap Work contributing to the Technical Roadmap, to improve our velocity or reduce the technical debt. echoes: unplanned/quick-win Work items completed to address issues quickly, without extensive planning. echoes: unplanned Any work item that isn’t part of the product or technical roadmap.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants