fix(settings): preserve unmanaged settings fields on partial saves - #2863
fix(settings): preserve unmanaged settings fields on partial saves#2863yyqdbngt wants to merge 1 commit into
Conversation
RockteMQ-AI
left a comment
There was a problem hiding this comment.
Summary
Clean fix for partial-writer data loss in saveGeneralSettings. When the general-settings UI and LLM-config UI each save a subset of fields, the null fields now correctly inherit from the stored value instead of silently overwriting it.
Findings
- [Info]
SettingsService.java:153— Consider a helper method to reduce null-check repetition as the field list grows (non-blocking)
Suggestions
- The existing
awsRegioncheck uses!StringUtils.hasText()(inherits on empty string too), while the new checks use== null(only inherits on null). This distinction is intentional per the PR description and the tests confirm it — just flagging for awareness that the two patterns coexist. - Tests cover both directions (general-save preserves LLM, LLM-save preserves notifications) and the explicit-clear edge case. Good coverage.
Verdict
Straightforward bug fix with solid test coverage. LGTM.
Automated review by github-manager
| // The settings blob has two partial writers: the general-settings save does not | ||
| // manage the LLM tuning values, and the LLM-config save does not manage the | ||
| // notification fields. An absent (null) value therefore inherits the stored one, | ||
| // while an explicit empty string still clears a text field. |
There was a problem hiding this comment.
Good documentation of the two-writer invariant. One consideration: if more fields are added later, the null-check boilerplate will grow linearly. A small helper method could keep this maintainable. Not blocking — just a thought for future iterations.
RockteMQ-AI
left a comment
There was a problem hiding this comment.
LGTM — defensive fix improving input validation and error handling.
Automated review by "github-manager-bot"
Summary
SettingsService.saveGeneralSettings, inherit the stored value for fields that apartial writer does not manage:
dingtalkWebhook,smsWebhook,emailRecipients,llmEngine,maxTokens,temperature.null) value now inherits the stored one; an explicit empty string stillclears a text field, so the existing clear-by-empty-string behaviour is unchanged.
Why
The persisted settings blob has two writers that each manage only part of the fields:
/api/settings/general/save,GeneralSettingsUpdateDTO)has no
maxTokens/temperatureproperties, so every general save nulled the LLMtuning and the next LLM config load silently fell back to the defaults;
LlmConfigService.saveConfig) builds the VO withoutdingtalkWebhook/smsWebhook/emailRecipients/llmEngine, so saving the LLMconfig wiped the notification channels and engine override.
Both were data-loss-on-save bugs in the opposite direction of each other.
Testing
cd server && mvn -Dtest=SettingsServiceTest test— Tests run: 46, Failures: 0, Errors: 0cd server && mvn -Dtest=LlmConfigServiceTest test— Tests run: 28, Failures: 0, Errors: 0