fix(settings): keep the page usable when a settings view fails to build - #507
Conversation
There was a problem hiding this comment.
Pull request overview
This PR hardens the plugin settings page rendering so that if one settings view throws during construction (including PHP Errors caused by corrupt stored account data), the rest of the settings page still renders, allowing users to recover by re-entering an API key or refreshing account data.
Changes:
- Wraps each settings view build in
PluginSettingsViewContextwith atry/catch (Throwable)so a single failing view is skipped instead of crashing the page. - Logs the original failure and shows a user-facing error notification identifying which settings section failed.
- Adds unit tests ensuring only the failing section is dropped, exactly one error notification is shown, and the original throwable is logged.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Context/Model/PluginSettingsViewContext.php | Builds each settings view in isolation; on failure logs + notifies and continues building remaining sections. |
| tests/Unit/Context/Model/PluginSettingsViewContextTest.php | Adds coverage for partial rendering, notification behavior, and logging when a view fails to build. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #507 +/- ##
=========================================
Coverage 94.29% 94.29%
- Complexity 2390 2391 +1
=========================================
Files 351 351
Lines 7655 7663 +8
=========================================
+ Hits 7218 7226 +8
Misses 437 437 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Corrupt account data - for example a mangled insurance format in the stored carrier capabilities - could make one settings view throw while the plugin settings page was being built, which took down the entire page. The user could then no longer re-enter their API key or refresh their data, the exact actions needed to recover. Each view is now built in isolation. A failing view is skipped, its original error is logged, and the user gets a notification naming the section that failed. Every other section keeps rendering, including the box for re-saving the API key or refreshing data, so the user can recover on their own. Fixes INT-1722 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
04c5213 to
5b82eb7
Compare
## [4.4.1](v4.4.0...v4.4.1) (2026-07-16) ### 🐛 Bug Fixes * **settings:** keep the page usable when a settings view fails to build ([#507](#507)) ([cf95dce](cf95dce))
|
🎉 This PR is included in version 4.4.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Stops one broken settings view from taking down the whole plugin settings page.
Corrupt account data - for example a mangled insurance format in the stored carrier capabilities - could make a single settings view throw while the page was being built, which crashed the entire page. That left the user unable to re-enter their API key or refresh their data, which are exactly the actions that would fix it. Each view is now built in isolation: a failing view is skipped, its original error is logged, and a notification names the section that failed, while every other section (including the API key / debug box) keeps working so the user can recover on their own.
Fixes INT-1722
🤖 Generated with Claude Code