[Sentry: APP-C3] HybridApp Android crash in CollectPersonalDetailsTaskViewHolder.updateModel — null cast to non-null String

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-C3

Impact (snapshot at filing)

• Users (last 7d): 9
• Users (total since first seen): 39
• Events: 167
• First seen: 2025-11-03
• Last seen: now (ongoing)
• Platform: Android (HybridApp, OldDot inbox)
• App version(s): 9.4.50-3 and earlier
• Mechanism: UncaughtExceptionHandler (fatal)
• Seer actionability: high

Stack trace (top frames, first-party only)

yapl.android.navigation.views.inbox.CollectPersonalDetailsTaskViewHolder.updateModel(CollectPersonalDetailsTaskViewHolder.kt:114)
yapl.android.navigation.views.inbox.InboxTaskAdapter.onBindViewHolder(InboxTaskAdapter.java:182)
yapl.android.navigation.views.inbox.InboxTaskAdapter.onBindViewHolder(InboxTaskAdapter.java:31)
androidx.recyclerview.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:7953)
androidx.recyclerview.widget.RecyclerView$Recycler.tryBindViewHolderByDeadline(RecyclerView.java:6742)

Suspected cause

CollectPersonalDetailsTaskViewHolder.updateModel casts a value to a non-null kotlin.String (a !! or an implicit platform-type cast) while binding the "collect personal details" inbox task. The value is null for some accounts, so the cast throws during RecyclerView layout and takes down the app.

The fix is to treat the field as nullable and render a sensible default, or to skip binding the row when the value is missing.

Reproduction

Unknown. It fires while the OldDot inbox list binds the collect-personal-details task, so it needs an account whose personal details task is missing the field that line 114 reads.

Related

• Expensify/Expensify#83022 (closed) tracked the same crash at CollectPersonalDetailsTaskViewHolder.kt:107. The line moved to 114 and the crash is active again, so this is filed fresh rather than reopened.
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022086528405115247989
• Upwork Job ID: 2086528405115247989
• Last Price Increase: 2026-08-09

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @DylanDylann (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022086528405115247989

[MelvinBot]

Issue Analysis

Root Cause: CollectPersonalDetailsTaskViewHolder.updateModel (CollectPersonalDetailsTaskViewHolder.kt:114) reads a value that is a Kotlin platform type / nullable, and forces it to a non-null kotlin.String (an implicit non-null cast or !!) while binding the "collect personal details" task row. For some accounts that field is null, so the cast throws null cannot be cast to non-null type kotlin.String during RecyclerView bind (onBindViewHolder → tryBindViewHolderByDeadline). Because it happens inside layout on the main thread it reaches the UncaughtExceptionHandler and is fatal.

This is a recurrence of the same crash previously tracked internally (referenced as Expensify/Expensify#83022, closed) at line :107. The line has since drifted to :114 and the crash is active again — either the same field regressed or an adjacent unguarded non-null access on the same view holder now throws.

Recommended Fix (belongs in Mobile-Expensify, not this repo): In updateModel, treat the field read at line 114 as nullable — bind a sensible default (e.g. empty string / placeholder) when it's null, or skip binding that row — instead of casting to a non-null String. Any unconditional !! or platform-type assignment to a non-null String on that line is the thing to remove.

⚠️ This fix is outside the Expensify/App repo. The crashing code (yapl.android.navigation.views.inbox.CollectPersonalDetailsTaskViewHolder) is native OldDot Android code that lives in Mobile-Expensify, which MelvinBot cannot access — so I can't provide code permalinks or open a PR for it. This needs an internal engineer with Mobile-Expensify access to make the change. It is not implementable by an external contributor working in Expensify/App.

Investigation details

Evidence chain

• Stack trace (from the issue) is first-party and unambiguous:

  CollectPersonalDetailsTaskViewHolder.updateModel(CollectPersonalDetailsTaskViewHolder.kt:114)
  InboxTaskAdapter.onBindViewHolder(InboxTaskAdapter.java:182)
  RecyclerView$Adapter.bindViewHolder / tryBindViewHolderByDeadline
  

• Mechanism is UncaughtExceptionHandler (fatal), Platform Android HybridApp, versions 9.4.50-3 and earlier — consistent with an NPE/ClassCastException-style null-cast during list binding.
• The prior internal issue for this exact class documented the message "null cannot be cast to non-null type kotlin.String" at :107, which pins the mechanism to a non-null String cast rather than, say, a bad adapter position.

Alternative explanations considered

• Adapter/position bug in InboxTaskAdapter — unlikely to be root cause: the throw is inside updateModel (the view holder), and the adapter frames are just the normal bind call path. A position/index bug would more likely throw IndexOutOfBounds in the adapter, not a cast failure in the view holder.
• Data-layer issue upstream (task synced without the field) — this is the trigger (an account whose collect-personal-details task is missing the field), but the correct defense is still to null-guard the render; the UI should not hard-crash on incomplete task data.

Why no repro / no test run

• Repro requires an account whose personal-details task is missing the specific field line 114 reads (unknown which accounts). This is an OldDot native Android crash; it cannot be reproduced or verified through web NewDot, so no browser test was run.

Confidence: Medium-High — the stack trace + the historical internal issue make the mechanism clear. It's not "High" only because I can't open Mobile-Expensify to confirm the exact field on line 114 or verify whether the 2018 fix regressed vs. a new sibling field.

---

Next Steps: This one needs to be routed to an internal engineer with Mobile-Expensify access to null-guard line 114. Reply with @MelvinBot <feedback> to refine this analysis.

[DylanDylann]

@GCyganek Are you interested in working on this issue?

[GCyganek]

I can take a look at it later today

[GCyganek]

@DylanDylann it looks like this happens when we get Inbox_Task_Get faster than Account_Get after the cache was just cleared (clearAccountCaches() for example when switching to Copilot account), user gets personal details card displayed on the Inbox screen and they do not have first or last name (because there are no null guards for these values):

I would:

• add null guards for user data values in updateModel in CollectPersonalDetailsTaskViewHolder.kt
• add default values for firstName and lastName in getData in CollectPersonalDetailsTask.js

This ensures we do not have crashes because of null values. Unfortunately this way we can load a card using null user which can result in user submitting the form without first/last name when their account has a first or last name set -> one of them can get cleared although it has been already set earlier. To fix this we can add a shouldBeDisplayed check to CollectPersonalDetailsTask.js which would not show the card if the user is null (Inbox_Task_Get returns before Account_Get with cleared cache). This way user needs to drag the screen to reload tasks:

Screen.Recording.2026-08-10.at.14.19.55.mov

Notice that I have added 15sec Account_Get delay to make sure I can reproduce it as it was hard to reproduce this bug without code changes

Alternatively we can also add subscribeToEvent(Event.ACCOUNT.UPDATED, this._reloadTasksIfBuiltWithoutUser) to InboxController.js to make sure that when we get Account_Get and tasks were loaded without the user data it would automatically refresh tasks list (_reloadTasksIfBuiltWithoutUser is a new function I'd implement in this case)

LMK what you think, especially whether you think if we need to automatically refresh the tasks when we get account data after inbox loads. I will post a PR tomorrow with the fix