Apply defaults when loading local configuration

[davidpaquin]

Summary

Default preferences were not being applied when loading local configuration.

This meant that settings that were not required/defaulted in the Joi spec (e.g. notification settings) would cause issues for consumers that expected those fields to be populated. In the issue linked below, this caused a rendering crash that would leave a transparent window over the main window, making nothing clickable.

Ticket Link

Fixes #3726

Checklist

• Has UI changes
• read and understood our Contributing Guidelines
• completed Mattermost Contributor Agreement
• executed npm run lint:js for proper code formatting

Device Information

This PR was tested on:
macOS Tahoe 26.3

Screenshots

Before:

Screen.Recording.2026-03-13.at.10.43.42.PM.mov

After:

Screen.Recording.2026-03-13.at.10.40.55.PM.mov

Release Note

Fixed issues related to default preferences not applying to local configuration

Change Impact: 🟡 Medium

Reasoning: The change is localized to the IPC handler that returns local configuration to renderer processes, ensuring default preference fields are applied. While the change is small and follows a safe defaults-overridden-by-local pattern, it affects multiple renderer components that consume configuration, and it fixes a critical user-facing crash.

Regression Risk: Moderate — the function alters the shape of config objects by populating previously-missing fields; if any renderer code relied on those fields being undefined, behavior could change. There are no unit tests added for this path, increasing risk slightly.

QA Recommendation: Perform focused manual QA: open Settings → Notifications and verify the tab renders without crashing and shows default notification preferences; confirm existing user preferences remain respected; smoke-test other settings panes (General, Spell Checker, Server Management) and basic app startup flows. Skipping manual QA is not recommended due to the UI crash this change addresses.

Generated by CodeRabbitAI

[mattermost-build]

Hello @davidpaquin,

Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

[coderabbitai]

📝 Walkthrough

Walkthrough

Return order in handleGetLocalConfiguration changed to spread Config.defaultData before Config.localData, so properties in localData override defaults while missing keys fall back to defaultData.

Changes

Cohort / File(s)	Summary
Configuration Default Values src/main/app/config.ts	Adjusted handleGetLocalConfiguration to spread Config.defaultData first, then Config.localData, ensuring local configuration overrides defaults and missing fields use defaults.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Apply defaults when loading local configuration' directly corresponds to the main change in the PR: spreading defaultData before localData to ensure defaults are applied when loading configuration.
Linked Issues check	✅ Passed	The PR addresses the core requirement from issue #3726: populating default preference fields for local configuration to prevent the renderer crash caused by missing 'bounceIconType' property.
Out of Scope Changes check	✅ Passed	The changes are limited to a single file with a focused modification to apply defaults during configuration loading, directly addressing the linked issue without introducing unrelated changes.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Tip

Migrating from UI to YAML configuration.

Use the @coderabbitai configuration command in a PR comment to get a dump of all your UI settings in YAML format. You can then edit this YAML file and upload it to the root of your repository to configure CodeRabbit programmatically.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/main/app/config.ts`:
- Around line 36-37: The current top-level spread of Config.defaultData and
Config.localData causes partial local notifications to overwrite defaults;
change the merge so nested notifications are merged too—e.g., after the
top-level spread merge, explicitly merge notifications by combining
Config.defaultData.notifications with Config.localData.notifications so fields
like bounceIconType are preserved when not provided locally; update the merge
logic around the existing spread usage of Config.defaultData and
Config.localData in config.ts (reference Config.defaultData, Config.localData,
notifications, bounceIconType) or use a deep-merge utility (lodash.merge) to
achieve the same result.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: f6415be0-4bad-40b2-83b2-ae9608d0bc1a

📥 Commits

Reviewing files that changed from the base of the PR and between 3357df5 and ff60950.

📒 Files selected for processing (1)

• src/main/app/config.ts

[devinbinnie]

LGTM! Thanks @davidpaquin!

[devinbinnie]

/update-branch