[Bug] : log level not changing

[w0l4i]

Dear Dev @therealaleph the log level logger in every form non other than info isn't working will , if we set on warn or trace at all time it shows info logs please check it for further way to fixing development and debugging we need richer logs tnx a lot

[therealaleph]

@w0l4i — confirmed worth investigating, but I need a few specifics to repro:

1. How are you setting the log level?

   • Env var: RUST_LOG=warn ./mhrv-rs (or RUST_LOG=trace)
   • CLI flag: ./mhrv-rs --log-level warn
   • Config: "log_level": "warn" in config.json
   • All of the above?

2. Which binary? mhrv-rs (CLI) or mhrv-rs-ui (UI) or Android APK?

3. Version? v1.8.0 or earlier?

4. What you expect to see vs. what you actually see:

   • At warn: expect only WARN + ERROR lines, but seeing INFO lines too?
   • At trace: expect TRACE + DEBUG + INFO + WARN + ERROR, but seeing only INFO?

The likely root cause depending on which knob:

RUST_LOG env var: this is what tracing-subscriber::EnvFilter::from_default_env() reads. If you set RUST_LOG=warn but it's still showing INFO, two possibilities:

• The env var wasn't picked up (e.g., set in shell A but mhrv-rs launched from shell B). Verify with echo $RUST_LOG in the same terminal that launches mhrv-rs.
• Or the binary was started before the env var was set (process inherits env at spawn).

--log-level CLI flag or config field: if either of these is present, they probably override RUST_LOG, but might not be wired to the subscriber correctly. That'd be a real bug — would need to look at src/main.rs to see where the level is plumbed.

Mixed tracing-subscriber filters: tracing-subscriber has a default filter that includes specific module paths. If mhrv-rs uses something like EnvFilter::new("mhrv_rs=info"), then setting RUST_LOG=warn only filters non-mhrv-rs modules; mhrv-rs's own modules stay at info. Module-path-bypass for the global level. Bug if so.

Quick repro check for version detection / config flow:

# CLI binary, env var
RUST_LOG=warn ./mhrv-rs 2>&1 | head -20
# Should show only WARN/ERROR lines

# Or with explicit module:
RUST_LOG=warn,mhrv_rs=warn ./mhrv-rs 2>&1 | head -20
# More aggressive — overrides any per-module default

If RUST_LOG=warn,mhrv_rs=warn works but plain RUST_LOG=warn doesn't, that confirms the per-module default override theory. In that case the fix is to make the explicit flag/config respect the user's intent and override any internal mhrv_rs=info default.

Reply with the answers + I'll either provide a config workaround or queue a fix in v1.8.x. Tracking this issue as a bug for now.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[w0l4i]

@w0l4i — confirmed worth investigating, but I need a few specifics to repro:

1. How are you setting the log level?

   • Env var: RUST_LOG=warn ./mhrv-rs (or RUST_LOG=trace)
   • CLI flag: ./mhrv-rs --log-level warn
   • Config: "log_level": "warn" in config.json
   • All of the above?

2. Which binary? mhrv-rs (CLI) or mhrv-rs-ui (UI) or Android APK?

3. Version? v1.8.0 or earlier?

4. What you expect to see vs. what you actually see:

   • At warn: expect only WARN + ERROR lines, but seeing INFO lines too?
   • At trace: expect TRACE + DEBUG + INFO + WARN + ERROR, but seeing only INFO?

The likely root cause depending on which knob:

RUST_LOG env var: this is what tracing-subscriber::EnvFilter::from_default_env() reads. If you set RUST_LOG=warn but it's still showing INFO, two possibilities:

• The env var wasn't picked up (e.g., set in shell A but mhrv-rs launched from shell B). Verify with echo $RUST_LOG in the same terminal that launches mhrv-rs.
• Or the binary was started before the env var was set (process inherits env at spawn).

--log-level CLI flag or config field: if either of these is present, they probably override RUST_LOG, but might not be wired to the subscriber correctly. That'd be a real bug — would need to look at src/main.rs to see where the level is plumbed.

Mixed tracing-subscriber filters: tracing-subscriber has a default filter that includes specific module paths. If mhrv-rs uses something like EnvFilter::new("mhrv_rs=info"), then setting RUST_LOG=warn only filters non-mhrv-rs modules; mhrv-rs's own modules stay at info. Module-path-bypass for the global level. Bug if so.

Quick repro check for version detection / config flow:

CLI binary, env var

RUST_LOG=warn ./mhrv-rs 2>&1 | head -20

Should show only WARN/ERROR lines

Or with explicit module:

RUST_LOG=warn,mhrv_rs=warn ./mhrv-rs 2>&1 | head -20

More aggressive — overrides any per-module default

If RUST_LOG=warn,mhrv_rs=warn works but plain RUST_LOG=warn doesn't, that confirms the per-module default override theory. In that case the fix is to make the explicit flag/config respect the user's intent and override any internal mhrv_rs=info default.

Reply with the answers + I'll either provide a config workaround or queue a fix in v1.8.x. Tracking this issue as a bug for now.

[reply via Anthropic Claude | reviewed by @therealaleph]

android and windows ui log level i didn't check the cli version

[therealaleph]

@w0l4i — UI binary (Windows + Android) only, not CLI. That narrows it.

Likely root cause: the UI binary's tracing-subscriber initialization happens at startup before the config is loaded. The log_level field in the config never reaches the subscriber.

Looking at src/bin/ui.rs quickly: the tracing_subscriber::registry() setup is in main() before load_form() reads the config. So:

// main() — runs first, locked at startup level
tracing_subscriber::registry()
    .with(EnvFilter::new("info"))  // hardcoded, ignores config
    .with(...)
    .init();

// later: config is loaded but log level can't be applied retroactively
let (form, err) = load_form();  // reads c.log_level = "warn", does nothing with it

That's the bug. The UI binary uses a hardcoded info filter regardless of RUST_LOG env var or config.

Fix queued for v1.8.2 (~10 LOC):

1. Read RUST_LOG env var first (using EnvFilter::try_from_default_env() instead of hardcoded EnvFilter::new("info"))
2. If RUST_LOG is unset, use a conditional filter that re-reads from the config after load_form

let env_filter = EnvFilter::try_from_default_env()
    .unwrap_or_else(|_| {
        // Fall back to config-based level if env var not set
        let lvl = load_form().0.log_level;
        EnvFilter::new(format!("mhrv_rs={lvl},info"))
    });
tracing_subscriber::registry()
    .with(env_filter)
    .with(...)
    .init();

Two changes: env var respected, config respected as fallback. With this:

• RUST_LOG=warn ./mhrv-rs-ui.exe → UI shows only WARN+ERROR
• Without RUST_LOG, config's "log_level": "warn" → UI shows only WARN+ERROR
• Default (neither set) → INFO+WARN+ERROR (current behavior)

For Android specifically: MhrvVpnService.kt calls into Rust via JNI to start the proxy. The Rust-side init goes through the same path as UI. Same fix applies — Android picks up the same env-or-config-driven filter.

Will land in v1.8.2 alongside the other small-but-overdue fixes (the corrected decoy detection message from #404, etc.). ~1-2 days from now if I batch enough small fixes to justify a release.

Workaround until v1.8.2: use the CLI binary (mhrv-rs.exe from the Windows zip, not mhrv-rs-ui.exe) when you specifically need verbose/quiet logs. CLI respects RUST_LOG correctly because its main is more straightforward.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[therealaleph]

@w0l4i — v1.8.2 shipped just now, fix is in. Build will be on releases page in ~30 min once CI completes.

What changed in src/bin/ui.rs:

1. load_form() now runs before install_ui_tracing(), so the saved log_level is available at boot.
2. install_ui_tracing(shared, &form.log_level) takes the level explicitly. Filter precedence is now:
   • RUST_LOG env var (if set) — explicit override
   • config.log_level from the loaded form — what users meant when they picked a level in the UI
   • info,hyper=warn — sensible default
3. The filter is wrapped in a tracing_subscriber::reload::Layer and the handle is stashed in a OnceLock. Save in the running UI now reinstalls the filter via apply_log_level(&self.form.log_level) — no restart required for a level change to take effect. (Exception: if RUST_LOG was set at boot, Save can't override it. Setting RUST_LOG is an explicit-priority signal, so we honor it both directions.)

For Android: the same code path applies — MhrvVpnService.kt calls start_proxy_jni which uses the same init_logging / install_ui_tracing layer in the desktop build. So once you upgrade the Android APK to v1.8.2, the saved log_level in the in-app config will apply. Hot-reload via Save in the Android UI should also work.

Verification (after upgrade to v1.8.2):

• Set "log_level": "warn" in your saved config → start UI → only WARN/ERROR show in the log panel
• Click the level combobox → switch to info → click Save → log panel immediately starts showing INFO+ events without restart
• RUST_LOG=trace ./mhrv-rs-ui.exe still works (env var beats config)

Thanks for the diagnostic detail in the original report — without the "config.log_level vs RUST_LOG" disambiguation in your message, I'd have spent longer narrowing whether the bug was in the form save path vs the subscriber init path. (The subscriber init path, as you pointed out.)

This issue stays open until you confirm v1.8.2 actually fixes the behavior on your end. Will close once you signal.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[w0l4i]

@w0l4i — v1.8.2 shipped just now, fix is in. Build will be on releases page in ~30 min once CI completes.

What changed in src/bin/ui.rs:

1. load_form() now runs before install_ui_tracing(), so the saved log_level is available at boot.

2. install_ui_tracing(shared, &form.log_level) takes the level explicitly. Filter precedence is now:

   • RUST_LOG env var (if set) — explicit override
   • config.log_level from the loaded form — what users meant when they picked a level in the UI
   • info,hyper=warn — sensible default

3. The filter is wrapped in a tracing_subscriber::reload::Layer and the handle is stashed in a OnceLock. Save in the running UI now reinstalls the filter via apply_log_level(&self.form.log_level) — no restart required for a level change to take effect. (Exception: if RUST_LOG was set at boot, Save can't override it. Setting RUST_LOG is an explicit-priority signal, so we honor it both directions.)

For Android: the same code path applies — MhrvVpnService.kt calls start_proxy_jni which uses the same init_logging / install_ui_tracing layer in the desktop build. So once you upgrade the Android APK to v1.8.2, the saved log_level in the in-app config will apply. Hot-reload via Save in the Android UI should also work.

Verification (after upgrade to v1.8.2):

• Set "log_level": "warn" in your saved config → start UI → only WARN/ERROR show in the log panel
• Click the level combobox → switch to info → click Save → log panel immediately starts showing INFO+ events without restart
• RUST_LOG=trace ./mhrv-rs-ui.exe still works (env var beats config)

Thanks for the diagnostic detail in the original report — without the "config.log_level vs RUST_LOG" disambiguation in your message, I'd have spent longer narrowing whether the bug was in the form save path vs the subscriber init path. (The subscriber init path, as you pointed out.)

This issue stays open until you confirm v1.8.2 actually fixes the behavior on your end. Will close once you signal.

[reply via Anthropic Claude | reviewed by @therealaleph]

i can confirm log level fixed in all variant : debug , error , trace , info in UI windows tested

warn log level set by ui :

2026-04-28T12:54:37.847843Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.847852Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 1, value: 1.0 } }
2026-04-28T12:54:37.847855Z TRACE event_result: Wait
2026-04-28T12:54:37.847856Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.847857Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: MouseMotion { delta: (0.0, 1.0) } }
2026-04-28T12:54:37.847859Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.847860Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by DeviceEvent::MouseMotion
2026-04-28T12:54:37.847861Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.847914Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 0, value: -1.0 } }
2026-04-28T12:54:37.847917Z TRACE event_result: Wait
2026-04-28T12:54:37.847918Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.847923Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 1, value: 2.0 } }
2026-04-28T12:54:37.847925Z TRACE event_result: Wait
2026-04-28T12:54:37.847926Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.847928Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: MouseMotion { delta: (-1.0, 2.0) } }
2026-04-28T12:54:37.847930Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.847931Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by DeviceEvent::MouseMotion
2026-04-28T12:54:37.847932Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.848135Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: CursorMoved { device_id: DeviceId(DeviceId(0)), position: PhysicalPosition { x: 92.0, y: 618.0 } } }
2026-04-28T12:54:37.848140Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.848142Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by WindowEvent::CursorMoved
2026-04-28T12:54:37.848143Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.848152Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.863556Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 0ns, current_frame_nr: 1947 }
2026-04-28T12:54:37.864445Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.864453Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.6134323s }, requested_resume: None })
2026-04-28T12:54:37.864456Z TRACE event_result: Wait
2026-04-28T12:54:37.864460Z TRACE winit event: UserEvent(RequestRepaint { viewport_id: "FFFF", when: Instant { t: 14615.6125474s }, frame_nr: 1947 })
2026-04-28T12:54:37.864463Z TRACE UserEvent::RequestRepaint scheduling repaint at Instant { t: 14615.6125474s }
2026-04-28T12:54:37.864464Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.864474Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 1, value: 1.0 } }
2026-04-28T12:54:37.864477Z TRACE event_result: Wait
2026-04-28T12:54:37.864477Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.864479Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: MouseMotion { delta: (0.0, 1.0) } }
2026-04-28T12:54:37.864481Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.864482Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by DeviceEvent::MouseMotion
2026-04-28T12:54:37.864483Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.864587Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: CursorMoved { device_id: DeviceId(DeviceId(0)), position: PhysicalPosition { x: 92.0, y: 619.0 } } }
2026-04-28T12:54:37.864705Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.864707Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by WindowEvent::CursorMoved
2026-04-28T12:54:37.864708Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.864728Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.880206Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 0ns, current_frame_nr: 1948 }
2026-04-28T12:54:37.881389Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.881398Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.6303766s }, requested_resume: None })
2026-04-28T12:54:37.881402Z TRACE event_result: Wait
2026-04-28T12:54:37.881406Z TRACE winit event: UserEvent(RequestRepaint { viewport_id: "FFFF", when: Instant { t: 14615.629197s }, frame_nr: 1948 })
2026-04-28T12:54:37.881409Z TRACE UserEvent::RequestRepaint scheduling repaint at Instant { t: 14615.629197s }
2026-04-28T12:54:37.881410Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.881421Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 0, value: -1.0 } }
2026-04-28T12:54:37.881423Z TRACE event_result: Wait
2026-04-28T12:54:37.881424Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.881426Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 1, value: 2.0 } }
2026-04-28T12:54:37.881427Z TRACE event_result: Wait
2026-04-28T12:54:37.881428Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.881429Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: MouseMotion { delta: (-1.0, 2.0) } }
2026-04-28T12:54:37.881431Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.881432Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by DeviceEvent::MouseMotion
2026-04-28T12:54:37.881434Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.881439Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 1, value: 1.0 } }
2026-04-28T12:54:37.881441Z TRACE event_result: Wait
2026-04-28T12:54:37.881441Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.881443Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: MouseMotion { delta: (0.0, 1.0) } }
2026-04-28T12:54:37.881445Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.881445Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by DeviceEvent::MouseMotion
2026-04-28T12:54:37.881446Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.881516Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: CursorMoved { device_id: DeviceId(DeviceId(0)), position: PhysicalPosition { x: 91.0, y: 622.0 } } }
2026-04-28T12:54:37.881523Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.881525Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by WindowEvent::CursorMoved
2026-04-28T12:54:37.881526Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.881682Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.896947Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 0ns, current_frame_nr: 1949 }
2026-04-28T12:54:37.897996Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.898005Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.6469835s }, requested_resume: None })
2026-04-28T12:54:37.898008Z TRACE event_result: Wait
2026-04-28T12:54:37.898012Z TRACE winit event: UserEvent(RequestRepaint { viewport_id: "FFFF", when: Instant { t: 14615.6459378s }, frame_nr: 1949 })
2026-04-28T12:54:37.898014Z TRACE UserEvent::RequestRepaint scheduling repaint at Instant { t: 14615.6459378s }
2026-04-28T12:54:37.898015Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.898025Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Motion { axis: 1, value: 1.0 } }
2026-04-28T12:54:37.898027Z TRACE event_result: Wait
2026-04-28T12:54:37.898028Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.898029Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: MouseMotion { delta: (0.0, 1.0) } }
2026-04-28T12:54:37.898031Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.898037Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by DeviceEvent::MouseMotion
2026-04-28T12:54:37.898038Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.898086Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: CursorMoved { device_id: DeviceId(DeviceId(0)), position: PhysicalPosition { x: 91.0, y: 623.0 } } }
2026-04-28T12:54:37.898089Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.898090Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by WindowEvent::CursorMoved
2026-04-28T12:54:37.898091Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.898097Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.913677Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 0ns, current_frame_nr: 1950 }
2026-04-28T12:54:37.914547Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.914556Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.6635346s }, requested_resume: None })
2026-04-28T12:54:37.914559Z TRACE event_result: Wait
2026-04-28T12:54:37.914563Z TRACE winit event: UserEvent(RequestRepaint { viewport_id: "FFFF", when: Instant { t: 14615.6626734s }, frame_nr: 1950 })
2026-04-28T12:54:37.914566Z TRACE UserEvent::RequestRepaint scheduling repaint at Instant { t: 14615.6626734s }
2026-04-28T12:54:37.914567Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.914575Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Button { button: 0, state: Pressed } }
2026-04-28T12:54:37.914577Z TRACE event_result: Wait
2026-04-28T12:54:37.914578Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.914639Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: MouseInput { device_id: DeviceId(DeviceId(0)), state: Pressed, button: Left } }
2026-04-28T12:54:37.914643Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.914644Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by WindowEvent::MouseInput
2026-04-28T12:54:37.914645Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.914668Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.930402Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 0ns, current_frame_nr: 1951 }
2026-04-28T12:54:37.931349Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.931359Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.6803368s }, requested_resume: None })
2026-04-28T12:54:37.931361Z TRACE event_result: Wait
2026-04-28T12:54:37.931365Z TRACE winit event: UserEvent(RequestRepaint { viewport_id: "FFFF", when: Instant { t: 14615.6793922s }, frame_nr: 1951 })
2026-04-28T12:54:37.931367Z TRACE UserEvent::RequestRepaint scheduling repaint at Instant { t: 14615.6793922s }
2026-04-28T12:54:37.931369Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.931381Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.947192Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 0ns, current_frame_nr: 1952 }
2026-04-28T12:54:37.947878Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.947886Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.6968654s }, requested_resume: None })
2026-04-28T12:54:37.947888Z TRACE event_result: Wait
2026-04-28T12:54:37.947892Z TRACE winit event: UserEvent(RequestRepaint { viewport_id: "FFFF", when: Instant { t: 14615.696182s }, frame_nr: 1952 })
2026-04-28T12:54:37.947894Z TRACE UserEvent::RequestRepaint scheduling repaint at Instant { t: 14615.696182s }
2026-04-28T12:54:37.947896Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.947906Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.963992Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 483.333332ms, current_frame_nr: 1953 }
2026-04-28T12:54:37.964864Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.964874Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.7138518s }, requested_resume: None })
2026-04-28T12:54:37.964877Z TRACE event_result: Wait
2026-04-28T12:54:37.964882Z TRACE winit event: UserEvent(RequestRepaint { viewport_id: "FFFF", when: Instant { t: 14616.196316132s }, frame_nr: 1953 })
2026-04-28T12:54:37.964885Z TRACE UserEvent::RequestRepaint scheduling repaint at Instant { t: 14616.196316132s }
2026-04-28T12:54:37.965116Z TRACE winit event: AboutToWait
2026-04-28T12:54:37.976407Z TRACE winit event: NewEvents(WaitCancelled { start: Instant { t: 14615.7141041s }, requested_resume: Some(Instant { t: 14616.196316132s }) })
2026-04-28T12:54:37.976412Z TRACE event_result: Wait
2026-04-28T12:54:37.976551Z TRACE winit event: DeviceEvent { device_id: DeviceId(DeviceId(918491)), event: Button { button: 0, state: Released } }
2026-04-28T12:54:37.976555Z TRACE event_result: Wait
2026-04-28T12:54:37.977683Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: MouseInput { device_id: DeviceId(DeviceId(0)), state: Released, button: Left } }
2026-04-28T12:54:37.977691Z TRACE event_result: RepaintNext(WindowId(WindowId(11470672)))
2026-04-28T12:54:37.977694Z TRACE RepaintNext of WindowId(WindowId(11470672)) caused by WindowEvent::MouseInput
2026-04-28T12:54:37.977696Z TRACE request_redraw for WindowId(WindowId(11470672))
2026-04-28T12:54:37.978014Z TRACE winit event: WindowEvent { window_id: WindowId(WindowId(11470672)), event: RedrawRequested }
2026-04-28T12:54:37.980633Z TRACE request_repaint_callback: RequestRepaintInfo { viewport_id: "FFFF", delay: 483.333332ms, current_frame_nr: 1954 }
2026-04-28T12:54:38.560849900Z [ui] starting proxy...
2026-04-28T12:54:38.561228900Z [ui] listening HTTP 127.0.0.1:8085 SOCKS5 127.0.0.1:8086
2026-04-28T12:54:38.561365Z WARN Listening HTTP on 127.0.0.1:8085 — set your browser HTTP proxy to this address.
2026-04-28T12:54:38.561371Z WARN Listening SOCKS5 on 127.0.0.1:8086 — xray / Telegram / app-level SOCKS5 clients use this.
2026-04-28T12:54:41.181041Z ERROR tunnel connect error for 149.154.167.92:80: bad response: no json in tunnel response: <title>Web App</title>

The script completed but did not return anything.

2026-04-28T12:54:45.116031Z ERROR batch failed (script AKfycbxt): got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch between mhrv-rs config and Code.gs (run a direct curl probe against the deployment to verify), (2) Apps Script execution timeout or per-100s quota tear (try lowering parallel_concurrency in config), (3) Apps Script internal hiccup (transient, retry next batch), or (4) ISP-side response truncation (#313 pattern, try a different google_ip). To distinguish (1) from the rest: set DIAGNOSTIC_MODE=true at the top of Code.gs + redeploy as new version — only AUTH_KEY mismatch returns this body in diagnostic mode.
2026-04-28T12:54:47.424464Z WARN batch failed (script AKfycbxz): io: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)
2026-04-28T12:54:48.156506Z WARN batch failed (script AKfycbz4): io: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)
2026-04-28T12:54:49.162156Z WARN batch failed (script AKfycbxL): io: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)
2026-04-28T12:54:49.432051Z WARN batch failed (script AKfycbzU): io: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (os error 10060)
2026-04-28T12:54:52.195263000Z [ui] stop requested
2026-04-28T12:54:52.195289400Z [ui] proxy stopped
2026-04-28T12:54:52.195358100Z [ui] proxy stopped gracefully
2026-04-28T12:54:52.389801Z ERROR batch failed (script AKfycbyY): got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch between mhrv-rs config and Code.gs (run a direct curl probe against the deployment to verify), (2) Apps Script execution timeout or per-100s quota tear (try lowering parallel_concurrency in config), (3) Apps Script internal hiccup (transient, retry next batch), or (4) ISP-side response truncation (#313 pattern, try a different google_ip). To distinguish (1) from the rest: set DIAGNOSTIC_MODE=true at the top of Code.gs + redeploy as new version — only AUTH_KEY mismatch returns this body in diagnostic mode.
2026-04-28T12:54:53.119704Z WARN batch failed (script AKfycbxP): timeout
2026-04-28T12:54:54.722639Z INFO batch: 1 ops → AKfycbxP, rtt=10.2535106s
2026-04-28T12:54:54.722661Z WARN batch failed (script AKfycbxP): timeout
2026-04-28T12:54:55.124333400Z [ui] starting proxy...
2026-04-28T12:54:55.124739Z INFO Loaded MITM CA from C:\Users\w0l4i\AppData\Roaming\mhrv-rs\config\ca/ca.crt
2026-04-28T12:54:55.124762200Z [ui] listening HTTP 127.0.0.1:8085 SOCKS5 127.0.0.1:8086
2026-04-28T12:54:55.124765Z INFO tunnel mux: 8 deployment(s), 30 concurrent per deployment
2026-04-28T12:54:55.124891Z WARN Listening HTTP on 127.0.0.1:8085 — set your browser HTTP proxy to this address.
2026-04-28T12:54:55.124894Z WARN Listening SOCKS5 on 127.0.0.1:8086 — xray / Telegram / app-level SOCKS5 clients use this.
2026-04-28T12:54:55.213473Z INFO SOCKS5 CONNECT -> 91.108.56.101:80
2026-04-28T12:54:55.213485Z INFO dispatch 91.108.56.101:80 -> full tunnel (via batch mux)
2026-04-28T12:54:56.732964Z INFO batch: 1 ops → AKfycbzk, rtt=4.6134556s
2026-04-28T12:54:57.345561Z INFO batch: 1 ops → AKfycbxP, rtt=10.016206s
2026-04-28T12:54:57.345589Z WARN blacklisted script AKfy...SIKN for 120s: 3 timeouts in 30s
2026-04-28T12:54:57.345591Z WARN batch failed (script AKfycbxP): timeout
2026-04-28T12:54:58.103382Z INFO SOCKS5 CONNECT -> 91.108.56.101:443
2026-04-28T12:54:58.103398Z INFO dispatch 91.108.56.101:443 -> full tunnel (via batch mux)
2026-04-28T12:54:58.103824Z INFO SOCKS5 CONNECT -> 91.108.56.101:80
2026-04-28T12:54:58.103837Z INFO dispatch 91.108.56.101:80 -> full tunnel (via batch mux)
2026-04-28T12:54:59.095732Z INFO SOCKS5 CONNECT -> 149.154.175.53:443
2026-04-28T12:54:59.095765Z INFO dispatch 149.154.175.53:443 -> full tunnel (via batch mux)
2026-04-28T12:54:59.109194Z INFO SOCKS5 CONNECT -> 149.154.175.53:80
2026-04-28T12:54:59.109209Z INFO dispatch 149.154.175.53:80 -> full tunnel (via batch mux)
2026-04-28T12:54:59.602276Z INFO pool pre-warmed with 5 connection(s)
2026-04-28T12:55:00.099347Z INFO SOCKS5 CONNECT -> 149.154.175.53:80
2026-04-28T12:55:00.099363Z INFO dispatch 149.154.175.53:80 -> full tunnel (via batch mux)
2026-04-28T12:55:00.099376Z INFO SOCKS5 CONNECT -> 149.154.175.53:443
2026-04-28T12:55:00.099385Z INFO dispatch 149.154.175.53:443 -> full tunnel (via batch mux)
2026-04-28T12:55:00.137698100Z [ui] stop requested
2026-04-28T12:55:00.137767Z INFO Shutdown signal received, stopping listeners
2026-04-28T12:55:00.137777600Z [ui] proxy stopped
2026-04-28T12:55:00.137789900Z [ui] proxy stopped gracefully
2026-04-28T12:55:00.571608Z INFO batch: 1 ops → AKfycbxL, rtt=2.4545755s
2026-04-28T12:55:01.172769Z INFO batch: 1 ops → AKfycbxP, rtt=10.0141612s
2026-04-28T12:55:01.172777Z WARN batch failed (script AKfycbxP): timeout
2026-04-28T12:55:01.362896Z INFO batch: 1 ops → AKfycbxz, rtt=2.2542777s
2026-04-28T12:55:02.754657900Z [ui] starting proxy...
2026-04-28T12:55:02.755047900Z [ui] listening HTTP 127.0.0.1:8085 SOCKS5 127.0.0.1:8086
2026-04-28T12:55:02.755219Z WARN Listening HTTP on 127.0.0.1:8085 — set your browser HTTP proxy to this address.
2026-04-28T12:55:02.755225Z WARN Listening SOCKS5 on 127.0.0.1:8086 — xray / Telegram / app-level SOCKS5 clients use this.
2026-04-28T12:55:07.724568Z ERROR batch failed (script AKfycbyY): got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch between mhrv-rs config and Code.gs (run a direct curl probe against the deployment to verify), (2) Apps Script execution timeout or per-100s quota tear (try lowering parallel_concurrency in config), (3) Apps Script internal hiccup (transient, retry next batch), or (4) ISP-side response truncation (#313 pattern, try a different google_ip). To distinguish (1) from the rest: set DIAGNOSTIC_MODE=true at the top of Code.gs + redeploy as new version — only AUTH_KEY mismatch returns this body in diagnostic mode.
2026-04-28T12:55:07.914666Z ERROR tunnel connect error for 149.154.175.53:80: bad response: no json in tunnel response: <title>Web App</title>

The script completed but did not return anything.

2026-04-28T12:55:08.455268Z ERROR tunnel connect_data error for 149.154.175.53:443: missing response in batch from script AKfycbzk
2026-04-28T12:55:10.483316Z ERROR batch failed (script AKfycbxz): got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch between mhrv-rs config and Code.gs (run a direct curl probe against the deployment to verify), (2) Apps Script execution timeout or per-100s quota tear (try lowering parallel_concurrency in config), (3) Apps Script internal hiccup (transient, retry next batch), or (4) ISP-side response truncation (#313 pattern, try a different google_ip). To distinguish (1) from the rest: set DIAGNOSTIC_MODE=true at the top of Code.gs + redeploy as new version — only AUTH_KEY mismatch returns this body in diagnostic mode.
2026-04-28T12:55:14.907509Z ERROR batch failed (script AKfycbyY): got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch between mhrv-rs config and Code.gs (run a direct curl probe against the deployment to verify), (2) Apps Script execution timeout or per-100s quota tear (try lowering parallel_concurrency in config), (3) Apps Script internal hiccup (transient, retry next batch), or (4) ISP-side response truncation (#313 pattern, try a different google_ip). To distinguish (1) from the rest: set DIAGNOSTIC_MODE=true at the top of Code.gs + redeploy as new version — only AUTH_KEY mismatch returns this body in diagnostic mode.
2026-04-28T12:55:15.521713Z WARN batch failed (script AKfycbxP): timeout
2026-04-28T12:55:18.326500Z WARN batch failed (script AKfycbxP): timeout
2026-04-28T12:55:18.326515Z ERROR tunnel connect_data error for 149.154.167.41:443: timeout