Post-Mortem: Home Screen Crash - March 28, 2026

postmortem-2026-03-28-home-screen-crash.md

Post-Mortem: Home Screen Crash (March 28, 2026)

Date of incident: Saturday, March 28, 2026 Duration: ~2 hours (8:00 AM - 10:00 AM MDT) Severity: Critical — app unusable for all testflight users Responders: Troy, Noman, Anton, Max, Jim, Dima A.

---

Summary

On Saturday morning, all test users on builds v19 and v20 experienced a crash on the home screen, making the app completely unusable. The root cause was a feature toggle: the Video Center promo row and creator row were turned off in production, and the app's home feed code assumed those components would always be present in the API response. When the API returned a response without those component types, the app crashed immediately on launch.

Timeline

Time (MDT)	Event
~8:00 AM	Test user reports app crashing on home screen
~8:15 AM	Team begins to investigate issue and ensures this is only happening in Native app
~9:15 AM	Team begins investigating Crashlytics reports
~9:30 AM	Root cause identified — firstWhere crash in _getFeedComponentContent() when creators and featuredPromo component types are missing from API response
~9:45 AM	Confirmed the Video Center promo and creator rows were toggled off in production, causing the API to omit those components
~9:55 AM	Feature rows re-enabled in production; users confirmed working

Root Cause

The home screen notifier (home_screen_notifier.dart) fetches the home page layout from GET /videos/pages/home, which returns a list of components. The code used Dart's firstWhere to find components by type:

final featuredCreatorsComponentId = components.firstWhere(
  (e) => e.type == ComponentType.creators,
);
final featuredPromoComponentId = components.firstWhere(
  (e) => e.type == ComponentType.featuredPromo,
);

firstWhere throws a StateError when no matching element exists. When the promo and creator rows were toggled off in production, the API correctly omitted them from the response — but the app assumed they would always be there.

This was never caught in testing because the feature was always enabled in test environments.

Impact

• All test users on v19 and v20 experienced an immediate crash on the home screen
• The app was completely unusable — no workaround was available to users
• Limited blast radius since the app is not yet in the App Store

Resolution

Immediate fix (March 28): Re-enabled the Video Center promo row and creator row feature toggles in production so the API response includes the expected component types.

Code fix (PR #181): Replaced firstWhere with firstOrNullWhere and added null handling so the app gracefully shows empty sections when component types are missing. Also replaced unsafe hard casts (as ComponentItemUserView) with whereType<T>() for safer type filtering.

Broader fix (PR #186): Audited the entire codebase and fixed the same pattern in 5 additional files:

• event_competition.dart — .first/.last on competitors list
• sidecast_api_service.dart — firstWhere on hosts/guests lists
• notification_message.dart — .first on notification activities
• podcast_inner_screen.dart — .first on podcast episodes list

An additional 10 lower-priority instances were documented for follow-up.

Contributing Factors

1. Environment parity gap: The Promo and Creator data was always available in testing but toggled off in production. The discrepancy meant this code path was never exercised before it hit real users.
2. No defensive coding on API boundaries: The app assumed the API would always return specific component types. The API schema (/swagger.json) defines components as a required array but with no minItems constraint — an empty array is a valid response.
3. No integration test for feature-off states: There was no test simulating the API response when these features are disabled.

Lessons Learned

What went well:

• Quick identification of the root cause
• Admin toggle (Promo Row) allowed an immediate fix without requiring an app release
• Team responded quickly on a Saturday morning

What we can improve:

• When investigating an issue check Crash Analytics early
• Empty state should be tested on the client in staging as much as possible
• Use firstOrNullWhere / firstOrNull as the default pattern when accessing API data — never assume a list contains a specific element
• Consider adding a linter rule or code review checklist item to flag firstWhere without orElse on API-sourced data

Action Items

Action	Owner	Status
Fix home feed firstWhere crash	Jim	Done (PR #181)
Fix remaining unsafe list access patterns	Jim	Done (PR #186)
Fix lower-priority UI/device list access patterns	Anton	In Progress (gist)
Add integration tests for feature-off API responses	TBD	Open
Ensure more team members have access to crash analytics in google console	TBD	Open