EXC_BREAKPOINT: _createPreparedCellForGlobalRow:withIndexPath:willDisplay: > oundEvents:regionOfInterest:

[sentry-io[bot]]

Sentry Issue: JETPACK-IOS-1BHM

EXC_BREAKPOINT: _createPreparedCellForGlobalRow:withIndexPath:willDisplay: > oundEvents:regionOfInterest:
  File "ReaderCardsStreamViewController.swift", in value
  File "ReaderCardsStreamViewController.swift", in ReaderCardsStreamViewController.cell
  File "ReaderCardsStreamViewController.swift", line 65, in ReaderCardsStreamViewController.tableView
  File "<compiler-generated>", in ReaderCardsStreamViewController.tableView
  File "<compiler-generated>", in ReaderCardsStreamViewController.tableView
...
(65 additional frame(s) were not displayed)

[dangermattic]

Thanks for reporting! 👍

[dvdchr]

The crash site is dequeueReusableCell(withIdentifier:) returning nil and being force-downcasted. I could update this method to use dequeueReusableCell(withIdentifier:for:) so that it always returns something, but I'm curious as to why this occurred in 25.0.

https://github.com/wordpress-mobile/WordPress-iOS/blob/ea97aa6c2d24bb22aeb38b57a20072b19fec3efd/WordPress/Classes/ViewRelated/Reader/ReaderCardsStreamViewController.swift#L93

In 25.0, we added a new stream to Reader, called 'Your Tags'. This stream uses ReaderStreamViewController and does not modify any logic in ReaderCardsStreamViewController which is exclusively used by the Discover stream. I don't think adding 'Your Tags' caused this crash, but the fact that it starts happening in 25.0 says otherwise.

Based on the stack trace and event breadcrumbs, the crash happened shortly after menuActionTriggered: was logged. Roughly, these were probably the steps taken based on reviewing several crash sessions:

• Navigate to the Reader tab
• Tap the Reader navigation button
• Tap the Discover stream (menuActionTriggered: is logged here)

Another condition is that users experiencing this seems to have 0 followed tags, identified by the select_interest_shown Tracks event when opening Discover. I couldn't reproduce this crash locally, but I noticed that the Tracks events were logged differently. Here's an example event log from a crash session:

🔵 Tracked: reader_discover_shown <list: Discover, source: reader, subscription_count: 1>
🔵 Tracked: select_interests_shown <subscription_count: 1>
🔵 Tracked: reader_discover_content_presented <>
🔵 Tracked: reader_discover_content_presented <>
🔵 Tracked: reader_dropdown_menu_opened <>

The reader_discover_content_presented event was fired twice. This event is fired after fetching content, so either the fetch method is called twice or a second view controller is created somewhere. Not sure if this oddity is related to the crash, though.

I'll continue the root cause investigation tomorrow, and if I still can't figure it out, I'll update the dequeueReusableCell method.

[dvdchr]

Found the repro steps and root cause. I've opened #23368 to fix this, along with more details in the PR.

The reader_discover_content_presented event was fired twice.

The duplicate reader_discover_content_presented is unrelated to this crash issue, but it's still an indication of a visual bug. When using an account with no site, the Reader tries to fetch the feed twice. The second fetch caused the 'Select Interests' screen to be dismissed. We can fix this behavior by removing the hideSelectInterestsView() call here, but this might introduce side effects.

I'll open a separate issue for this.

[sentry-io[bot]]

Sentry Issue: JETPACK-IOS-1BV1

[kean]

Looks like it's been fixed.