Skip to content

fix(wallpaper): keep recovery state when Lively omits a running player - #296

Merged
Lucas1479 merged 4 commits into
mainfrom
codex/issue-233-wallpaper-recovery
Nov 7, 2026
Merged

Lucas1479 merged 4 commits into
mainfrom
codex/issue-233-wallpaper-recovery

Conversation

@Lucas1479

@Lucas1479 Lucas1479 commented Nov 6, 2026 •

Copy link
Copy Markdown
Member

Refs #233. Keep the issue open: this fixes the Amadeus managed WebView2 recovery path; it does not change Lively's RPCs or certify its entire wallpaper registry.

What changed

Lively can acknowledge a project close while the player is still running. The #233 offline counterexample on main (53f8f4f2) returned an empty inventory, discarded the recovery journal, and requested shutdown of the owned host while the simulated scene was still present.

The Windows helper compares the number of live Amadeus WebView2 players with the number of entries Lively reports for the managed project. If there are more players than entries, cleanup is refused. A span player can keep its original launch display after Lively moves its entry to a new primary monitor, so the helper does not match launch display numbers. Restoration still checks the target monitor; a player can veto cleanup but cannot authorize killing a process or replacing a wallpaper.

This PR adds a two-second window after a project-scoped Close. If a player is still unaccounted for or inspection returns access denied, the helper rechecks both the Lively list and Windows processes within that window. Windows maps command-line query errors from NTSTATUS so that a terminating process receives the same access-denied handling as an image query. Denial alone never proves exit. A persistent discrepancy or inspection failure retains the journal and reports the failure. No dependency, setting, or journal migration.

Stock Lively 2.2.1.0 desktop evidence (earlier commit)

Product commit: 5658a379450978148c53ce6eb732053d555b6fc5. Disposable GitHub-hosted Windows Server 2025 VMs (build 26100, Explorer, one virtual display). The official installer matched SHA-256 98f4e96bb8e2c416384eeaf48016eadaea9dce8263b8d212052775ebcf2d7e34; each job recorded hashes for the installed EXE, core DLL and WebView2 wrapper. No DLL or production helper was patched in the final runs. The test supervisor drove the real Electron application and checked native player state, the recovery journal and host ownership independently of the UI.

Final scenario Observed result
Empty desktop, Amadeus-owned host Four normal mount/quit cycles across the owned-host job and independent cold control. Each mounted the actual player/Slice, then released the player and host, cleared the journal and preserved the Windows wallpaper setting.
Existing scene and shared host Two cases: restored original fixture A; when the user selected B during the session, B remained. The same shared process stayed alive, Lively options were unchanged and the managed wrapper was gone.
Loss of a mounted helper Helper process-tree fault: the journal survived the interruption; the separate production recover entry point returned restored, with zero managed players, no owned host, and the original Windows wallpaper.
Close acknowledgement without removal Stock negative control: temporarily withheld only the synthetic project’s metadata. The project remained listed and its player alive. Quit and a recovery attempt retained the journal and host. After restoring the metadata, recovery succeeded, the wrapper and owned host exited and the journal cleared.
Interrupted Set, original receiver still alive Separate Pending test: terminated the test helper without killing Lively, after a real wrapper appeared during the outstanding request. Recovery explicitly refused while the same receiver lived; the journal stayed byte-identical. After confirmed exit of that receiver, recovery succeeded, with zero players, no running host and the original Windows wallpaper.

Nine desktop cases passed on 5658a379; they were not rerun on 6ca878ef. The full spontaneous combination “settled false-empty inventory + no-op Close” was not observed. An empty list while Set is still Pending is not that failure; the induced Close failure above had a nonempty registry. The complete combined case remains covered by the offline counterexample and native process tests. No physical multi-monitor or general third-party-plugin qualification is claimed.

Regression coverage on 6ca878ef

On a clean export with Python 3.12.10 and pytest 8.4.2, 109 helper tests passed. Running the same tests with the earlier 5658a379 helper failed the span/primary-display switch case and both NTSTATUS cases; the two refusal controls still passed. Ruff 0.16.3 passed on all three changed Python files. The span case uses a simulated Lively registry; physical multi-monitor behavior has not been validated. Current Electron Windows CI (includes parent lifecycle tests).

Earlier failures and CI on 5658a379

  • First uninstrumented desktop run: genuine normal quit failed with WinError 5; the journal was retained. Diagnostic trace localized the denial to querying the terminating wrapper’s executable path. The fix in 5658a379 handled that image-query race without relaxing persistent access failures.
  • Earlier cold start exceeded the stock Set RPC deadline. The Pending fence held. The independent final Pending test exercises the recovery boundary; it is not a claim that arbitrary cold starts cannot time out.
  • Electron Windows CI on 5658a379: 105 Python helper tests and 706 Electron tests passed, including attached, crash and normal parent lifetime. Unpacked build and packaged wallpaper smoke passed.
  • Separate CI finding: the first Windows model-less smoke failed at the plugin store's post-restart scheduledInstall assertion while installing a theme. That failure is separate from the nine stock-wallpaper results. On the targeted rerun at the identical commit, the same source-mode smoke passed without a plugin or test change. The cause of the first failure is unconfirmed. The rerun also passed the packaged app and catalog recovery roundtrip; all 16 GitHub checks passed on 5658a379.

@Lucas1479
Lucas1479 marked this pull request as ready for review November 6, 2026 11:42
@Lucas1479
Lucas1479 merged commit 6a48097 into main Nov 7, 2026
16 checks passed
@Lucas1479
Lucas1479 deleted the codex/issue-233-wallpaper-recovery branch November 7, 2026 17:28
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.

1 participant