The Settings Log Level dropdown (error / warn / info / debug / trace) is persisted on AppSettings.log_level, but that value is never applied to the logger.
In src-tauri/src/lib.rs the filter is fixed at plugin construction:
There is no startup read of saved settings and no path that updates the filter when the user saves Settings. The control is misleading: users think they enabled verbose logging when release builds remain at Info.
Steps to Reproduce
Settings → Log Level Debug (or Trace) → Save.
Restart (or continue in-session).
Run a stage that emits subprocess output.
Open the log via Open Log Folder.
Expected Behaviour
Saved level is applied on startup and again immediately on Save.
debug / trace actually increase what is written to iccery.log without needing a debug binary.
Actual Behaviour
Level is compile-time only (Debug vs Info from cfg!(debug_assertions)).
Dropdown and log_level in settings.json have no effect on filtering.
Scope & Technical Requirements
Map log_level string → log::LevelFilter (invalid/missing → Info in release, Debug in dev).
Apply on startup as soon as settings and the log plugin are available.
Apply again when Settings is saved (no restart required if the plugin allows; if not, apply on startup and state that clearly in the UI).
Optional one-line info banner after apply: effective level + log path (helps support).
Short Settings hint under the dropdown once behaviour is correct (“Applies on Save” / “Applies on next launch” as accurate).
Use whatever tauri-plugin-log v2 supports for post-init level changes; if the filter is immutable after build(), document that and still fix startup-from-settings so persistence is not dead.
Acceptance Criteria
Saving Debug/Trace changes what appears in iccery.log (or on next launch if runtime change is impossible — must be documented in UI).
Restart restores and applies the last saved level.
Invalid stored values do not crash.
Open Log Folder / Copy Path unchanged.
Dependencies
Extends #139 (closed). No other feature dependencies.
### Description
The Settings **Log Level** dropdown (`error` / `warn` / `info` / `debug` / `trace`) is persisted on `AppSettings.log_level`, but that value is **never applied** to the logger.
In `src-tauri/src/lib.rs` the filter is fixed at plugin construction:
```rust
.level(if cfg!(debug_assertions) {
log::LevelFilter::Debug
} else {
log::LevelFilter::Info
})
```
There is no startup read of saved settings and no path that updates the filter when the user saves Settings. The control is misleading: users think they enabled verbose logging when release builds remain at `Info`.
### Steps to Reproduce
1. Settings → Log Level **Debug** (or Trace) → Save.
2. Restart (or continue in-session).
3. Run a stage that emits subprocess output.
4. Open the log via **Open Log Folder**.
### Expected Behaviour
- Saved level is applied on **startup** and again **immediately on Save**.
- `debug` / `trace` actually increase what is written to `iccery.log` without needing a debug binary.
### Actual Behaviour
- Level is compile-time only (`Debug` vs `Info` from `cfg!(debug_assertions)`).
- Dropdown and `log_level` in settings.json have no effect on filtering.
### Scope & Technical Requirements
1. Map `log_level` string → `log::LevelFilter` (invalid/missing → `Info` in release, `Debug` in dev).
2. Apply on startup as soon as settings and the log plugin are available.
3. Apply again when Settings is saved (no restart required if the plugin allows; if not, apply on startup and state that clearly in the UI).
4. Optional one-line `info` banner after apply: effective level + log path (helps support).
5. Short Settings hint under the dropdown once behaviour is correct (“Applies on Save” / “Applies on next launch” as accurate).
Use whatever `tauri-plugin-log` v2 supports for post-init level changes; if the filter is immutable after `build()`, document that and still fix **startup-from-settings** so persistence is not dead.
### Acceptance Criteria
- [ ] Saving Debug/Trace changes what appears in `iccery.log` (or on next launch if runtime change is impossible — must be documented in UI).
- [ ] Restart restores and applies the last saved level.
- [ ] Invalid stored values do not crash.
- [ ] Open Log Folder / Copy Path unchanged.
### Dependencies
- Extends #139 (closed). No other feature dependencies.
gronod
added this to the Milestone 10: Production Ready Features (v0.6.0) milestone 2026-08-31 00:03:22 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
The Settings Log Level dropdown (
error/warn/info/debug/trace) is persisted onAppSettings.log_level, but that value is never applied to the logger.In
src-tauri/src/lib.rsthe filter is fixed at plugin construction:There is no startup read of saved settings and no path that updates the filter when the user saves Settings. The control is misleading: users think they enabled verbose logging when release builds remain at
Info.Steps to Reproduce
Expected Behaviour
debug/traceactually increase what is written toiccery.logwithout needing a debug binary.Actual Behaviour
DebugvsInfofromcfg!(debug_assertions)).log_levelin settings.json have no effect on filtering.Scope & Technical Requirements
log_levelstring →log::LevelFilter(invalid/missing →Infoin release,Debugin dev).infobanner after apply: effective level + log path (helps support).Use whatever
tauri-plugin-logv2 supports for post-init level changes; if the filter is immutable afterbuild(), document that and still fix startup-from-settings so persistence is not dead.Acceptance Criteria
iccery.log(or on next launch if runtime change is impossible — must be documented in UI).Dependencies