ScheduleManager.saveSchedule - EXC_BAD_ACCESS crash

[aaravgarg]

Summary

• Wrap AwesomeNotifications.createNotification call in try-catch
• Prevents native EXC_BAD_ACCESS crash in ScheduleManager.saveSchedule (internal AwesomeNotifications pod method)
• The crash occurs in the native iOS notification scheduling code, this fix catches the exception at the Dart bridge level

Crash Stats

• Events: 72
• Users affected: 63
• Crashlytics: View in Console

Test plan

• Verify notifications still show correctly
• Verify notification scheduling still works

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a try-catch block around the AwesomeNotifications.createNotification call to prevent a native crash on iOS. This is a good defensive measure. My review includes a suggestion to improve the error handling within the new catch block to ensure that these failures are properly logged and tracked, rather than being silently ignored in debug logs.

[gemini-code-assist]

While adding a try-catch block is the correct approach to prevent the app from crashing, logging the error at the debug level is insufficient for an issue that was causing a native crash. Such failures should be logged as errors to ensure they are tracked in error monitoring services like Crashlytics. This will help in monitoring the frequency of this failure and verifying that the fix is effective.

Please change the catch block to capture the stack trace and use Logger.handle to report it as a proper error.

Suggested change

	} catch (e) {
	Logger.debug('Failed to create notification: $e');
	}
	} catch (e, s) {
	Logger.handle(e, s, message: 'Failed to create notification');
	}

[mdmohsin7]

closed in #4628

[github-actions]

Hey @aaravgarg 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our roadmap and vision

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community! 💜