Skip to content

fix(config): default sensitive diagnostics to off, matching the UI copy - #3218

Open
xiechimon wants to merge 1 commit into
GCWing:mainfrom
xiechimon:fix/3213-sensitive-diagnostics-default-off
Open

xiechimon wants to merge 1 commit into
GCWing:mainfrom
xiechimon:fix/3213-sensitive-diagnostics-default-off

Conversation

@xiechimon

Copy link
Copy Markdown
Contributor

Summary

The settings UI promises sensitive diagnostics are off by default in all three locales (zh-CN/zh-TW/en-US: "默认关闭" / "Off by default"), and the capability docs say "Enable only when explicitly needed and after reviewing the privacy risk". The backend defaults say the opposite:

  • AppLoggingConfig::include_sensitive_diagnostics used #[serde(default = "default_true")], so a config file without the key deserialized to true
  • the Default impl set include_sensitive_diagnostics: true
  • the ai-adapters runtime AtomicBool started at true (fail-open before the config layer applied the saved preference)
  • the frontend FrontendLogLevelSync fallbacks (3 sites) and the logger.ts initial value used true, while the settings page fallback used ?? false, so even the frontend disagreed with itself

Net effect for a fresh install: prompts, model request/response payloads, tool arguments and file paths get written to local logs even though the UI says they don't, until the user explicitly turns the switch off.

Fixes #3213

Changes

  • config-contracts/types.rs: serde default and Default impl now produce false; the pinned defaults test flips with them (app_logging_defaults_to_sensitive_diagnostics_disabled)
  • ai-adapters/diagnostics.rs: AtomicBool starts false (fail closed until the config layer applies the saved preference)
  • FrontendLogLevelSync.ts: the three no-saved-preference fallbacks return false, matching the settings page and the backend
  • logger.ts: initial module value false with a comment

Explicit user values (either polarity) are untouched everywhere: the config manager still applies the saved preference on load and on change, and the toggle still works the same. Only the no-preference default flips, to the value every user-facing surface already documents.

Testing

Red-green: renamed and flipped the Rust defaults test first (assert!(config.include_sensitive_diagnostics) fails on base), then applied the fix; the two new vitest cases in FrontendLogLevelSync.test.ts pin the off-by-default fallbacks (both fail on base with expected false, received true).

  • cargo test -p openbitfun-config-contracts --lib: 92 passed
  • cargo test -p openbitfun-ai-adapters --lib: 287 passed (includes the diagnostics toggle test and the request-body logging tests, which set the flag explicitly)
  • cargo test -p openbitfun-core --lib service::config: 58 passed (includes the export round-trip fixture that sets the preference explicitly)
  • vitest run src/infrastructure/config: 532 passed across 65 files
  • cargo fmt --check clean on both touched crates; eslint exit 0 on the touched TS files; the prettier warnings on these files are pre-existing (base versions report identically)

AI-assisted with human review; testing level: fully tested (all suites above run locally against this branch).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: 界面写“敏感诊断信息默认关闭”,但后端配置当前实际默认是 true

1 participant