Provide one shared Windows session-ending signal and wire it for production use

Open
  • Is something wrong?
#1,575 3 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
desktop, operating-systems

Research direction

Start by inspecting the shared layer around WebSocketClientBase.cs and the tray host's session-event or window handling and registration paths. Choose one of the specified Windows session-ending mechanisms, then add the abstraction, implementation, production wiring, and tests for real wiring and substitution. Run ./build.ps1 and the three listed Shared, Tray, and Connection test projects; done means all pass without a real shutdown or WSL.

Written by the indexing model from the issue text.

Description

clawsweeper:fix-shape-clear clawsweeper:queueable-fix impact:ux-friction issue-rating: 🌊 off-meta tidepool no-stale P2

What

Three existing issues each guard a different call site that can start wsl.exe during a Windows session-end sequence:

  • #1572 — the process-start boundary of the managed-local provenance probe
  • #1573 — the tray's keep-alive entry points
  • #1574 — the reconnect retry loop

All three need the same input: a reliable, injectable answer to "is a Windows session-end sequence in progress?". No such source exists in the repository today, and #1572 deliberately left the concrete Windows wiring out of its scope. As the reviews on #1573 and #1574 note, three independently-defined seams would be incompatible with each other, or would never be wired to anything real.

This issue owns that prerequisite: the abstraction, a concrete Windows source, and its production registration. It is the contract the other three implement against.

Where

  • The contract must be consumable from src/OpenClaw.Shared — WebSocketClientBase.cs (#1574) lives there, and that assembly must not gain a Win32 or tray dependency. Put the abstraction in the shared layer; put the Windows implementation where the host can observe session events.
  • A concrete source is Microsoft.Win32.SystemEvents.SessionEnding, or the WM_QUERYENDSESSION / WM_ENDSESSION pair handled on the tray's own window. Either is acceptable; where a window already exists, prefer the message pair, because it lets the process act before the session ends rather than only observing that it is ending.

Required behaviour

  1. One injectable abstraction answering "is the Windows session ending?", consumed by all three call sites — a single source of truth, no per-call-site re-derivation of the state.
  2. A production implementation actually wired up in the tray host, not left as a null / always-false default in a released build. A seam that is never connected is worse than none: it looks fixed and is not.
  3. Substitutable in tests: forcing "ending" must not require shutting Windows down.
  4. Registering it must not change behaviour when no session end is in progress.
  5. Do not use Environment.HasShutdownStarted as the whole answer; on its own it is not reliable evidence that a session-end sequence is in progress.
  6. If the mechanism can observe the transition (a session end has been requested) and not merely a latched state, expose that. #1574 needs to react to a session end that begins during an in-flight backoff wait, and #1572 prefers to decline as early as possible.

Scope

  • Add the abstraction, the Windows implementation and its registration. That is the whole of this issue.
  • Do not change the three consumer call sites — #1572, #1573 and #1574 own those, and each owns exactly one production file (plus, in #1573's case, the keep-alive cancellation boundary under discussion there).
  • Do not refactor AppShutdownCoordinator or the ordered-shutdown design recorded in docs/ARCHITECTURE.md.
  • Do not add a new user-facing setting.

This should stay a small change: one new contract, one new implementation, one registration. Keeping it that small is deliberate — a previous single issue covering all three spawn paths produced a fix artifact that spanned three subsystems and was rejected as too broad for autonomous execution.

Acceptance

./build.ps1
dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
dotnet test ./tests/OpenClaw.Connection.Tests/OpenClaw.Connection.Tests.csproj --no-restore

Required regression test

  • A test asserting the wiring is real: with the host configured as in production, the abstraction the consumers receive is the Windows implementation, not a default no-op. This is the failure mode that otherwise ships silently.
  • A test asserting the substitutable path: an implementation reporting "ending" is observed as ending by a consumer, and one reporting "not ending" is observed as not ending — without any real session end.
  • The test suite must not require an actual shutdown, a real wsl.exe, or WSL to be installed.

Related

Prerequisite for #1572, #1573 and #1574 — they depend on this contract and should not be closed in favour of it. #1571 is the evidence umbrella for the underlying defect.

What I can and cannot contribute

  • I can confirm the reported behaviour on Windows 11 Home China build 10.0.26300 with OpenClaw Companion 2026.9.4.0, including the Event 1074 → Event 26 ordering and tray-log excerpts during teardown.
  • I do not have a working build environment for this repository, so I cannot run ./build.ps1 or the test projects. Someone else needs to verify.
Dominant language
C#
Stars
2.2k
Forks
336
Avg merge
3d 18h
Merged PRs (30d)
177

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.