[shaohuzhang1]

fix: simple application error dispaly

[shaohuzhang1]

Review of the diff

The change is small and mostly reasonable, but there are a few things worth flagging.

1. Unused null fallback on JSON.stringify

return JSON.stringify(value, null, 2) ?? ''

JSON.stringify only returns undefined when the input is undefined, a function, or a symbol — all of which are already excluded by the earlier typeof checks (or by value == null). Realistically this ?? '' is dead code. It's harmless but can be simplified:

return JSON.stringify(value, null, 2)

2. Behavior change for string values isn't validated

if (typeof value === 'string') return value

If the backend previously returned a string like "{}" (common serialized empty object), you'd now render "{}" in the editor instead of an empty string, whereas the object branch treats {} as unconfigured. This asymmetry could cause UX inconsistency depending on whether the backend sends a stringified or structured value. Consider normalizing string content too, e.g.:

if (typeof value === 'string') {
  const trimmed = value.trim()
  if (!trimmed || trimmed === '{}' || trimmed === 'null') return ''
  return value
}

Only do this if you're confident about the backend contract.

3. Non-plain objects

typeof value === 'object' && !Array.isArray(value) still passes for Date, Map, etc. Not an issue if the backend always sends plain JSON, but if you want to be strict:

Object.getPrototypeOf(value) === Object.prototype

4. Comment language mismatch

The new JSDoc is in Chinese while surrounding types (LongTermSettingData, SelectedKnowledge, ApplicationSettings) are English naming. Minor style inconsistency — align with repo conventions.

5. No type guard input schema

detail.mcp_servers appears typed as possibly-string already (given ?? '' before). If so, normalizeMcpServers is widening the actual runtime handling beyond what the type promises. That's fine defensively, but update the type of mcp_servers if it can actually be unknown | object at runtime — otherwise downstream code that assumes a string may still break.

6. Missing test for null

The function handles null/undefined via value == null, but there's no explicit test shown. Please ensure unit tests cover: null, undefined, '', plain string, {}, {a:1}, array, and primitive number/bool (which will hit JSON.stringify(123) → "123" — is that desired?). A primitive like true becoming "true" may be an unexpected pass-through — consider rejecting primitives other than string explicitly.

Suggested consolidated version

function normalizeMcpServers(value: unknown): string {
  if (value == null) return ''
  if (typeof value === 'string') return value.trim() === '{}' ? '' : value
  if (typeof value !== 'object' || Array.isArray(value)) return ''
  if (Object.keys(value as object).length === 0) return ''
  return JSON.stringify(value, null, 2) || ''
}

This drops the dead ?? '', ignores non-object primitives, and keeps the empty-object rule. Verify behavior with your existing consumers before adopting.