Verify SetStdHandle GUI stderr redirect (#2137/PR#2614) doesn't interfere with WebView2/Tauri #2615

Activity

1. malibio commented on Oct 12, 2026

   

   malibio

   on Oct 12, 2026

   Collaborator

   More actions

   Verification on a Windows 11 ARM64 VM

   Setup: the published v0.3.5 x64 installer (NodeSpace_0.3.5_x64_en-US.msi), release build, running under x64 emulation in a UTM virtual machine on an Apple Silicon Mac. Windows 11 24H2, build 26100.4349 at install, 26100.9457 after a Windows Update reboot.

   Results

   • Launch and WebView2: no regression observed. The app launches, the UI renders, creating a node works with no errors, and the View menu actions work.
   • The redirect is applied. On the first launch after install, the GUI process's own tracing output (nodespace_app_lib INFO lines, 2,091 bytes) landed in %USERPROFILE%\.nodespace\logs\nodespace-app.log, and nodespace-app-error.log was created. On later launches both files are recreated after deletion and are held open by the running app: an exclusive open fails with a sharing violation while NodeSpace runs and succeeds after it quits. So SetStdHandle took effect.
   • Not reproduced on later launches. After the reboot, neither the startup tracing nor the println! fired by View → Toggle Sidebar (used through the menu bar item, not a shortcut) reached nodespace-app.log, which stayed at 0 bytes across two launches. Ruled out: HOME (the redirect uses dirs::home_dir()), the open mode (create + append), the prior state of the files (deleted and recreated), and the click path. Not determined: whether this is a NodeSpace issue or an effect of the OS update, x64 emulation or the VM. The OS build changed between the launch that logged and the ones that did not.
   • Acceptance criterion 3 as written can't be performed. The SchemaNode::from_node diagnostic was removed when SchemaNode became one wire type, so the original trigger no longer exists. The substitute used was the menu println! above.

   Side observations

   • The skill installer sidecar exited 0xC000001D (illegal instruction) under emulation. It is non-fatal and logged as a warning. Likely an emulation limitation, not confirmed.
   • The daemon's could not determine models directory: $HOME is unset error was found during this run, filed as Local model management is disabled on Windows because the models directory is resolved from $HOME #3761 and fixed in Resolve the GGUF models directory through the daemon's NodeSpace home (closes #3761) #3762.

   Remaining

   A run on x64 Windows hardware, or a fresh install of a build containing the #3761 fix, to separate a product issue from an environment one. A Windows build of the merged branch exists as a workflow artifact for that.
2. malibio commented on Oct 12, 2026

   

   malibio

   on Oct 12, 2026

   Collaborator

   More actions

   Update: verification complete, defect tracked in #3768

   Further runs on the same VM narrowed the later-launch silence reported above to the launch method, not the OS update:

   • Launched from the installer's finish screen or from PowerShell, the GUI process's output (tracing startup lines through the shutdown sequence) lands in nodespace-app.log.
   • Launched from the Start menu, which is how users and the autorun entry launch it, nothing lands, across seven launches on two builds. The redirect's files are opened and held by the app in that case (exclusive open fails while it runs, succeeds after it quits), and a launch that re-extracted the daemon sidecars was still silent.

   Answers to what this issue asked:

   • No WebView2/Tauri interference: the app launches, renders, creates nodes and handles menu actions on every launch path.
   • The original from_node trigger no longer exists, so a diagnostic was observed through the app's own startup and shutdown output and the menu println!.
   • The redirect does not deliver output in the Start-menu launch path. That is a defect in the feature this issue verified, tracked as Windows GUI app's log redirect delivers no output when the app is launched from the Start menu #3768 with the full launch table, what was ruled out, and what is not yet determined (the mechanism, and reproduction on x64 hardware outside a VM).

   Closing this as verified; the open defect continues in #3768.
3. malibio

   closed this as completedon Oct 12, 2026