lorenzozaneandGitHub 127ec0f027 fix(daemon): defer invalid-payload until launcher state is eligible (#7520) ...

On a fresh Windows install the launcher has no versions/0.16.1 tree yet,
so resolvePayloadExecutable returns null and
prepareLegacyPayloadDesktopHandoff immediately returned invalid-payload.
That ran before the eligibility check (active == lastSuccessful,
generation 0), masking the real state as a payload error. The daemon
then logged [packaged desktop handoff] skipped { reason:
'invalid-payload' } and left trustedWebOriginPort null, so /api fell
through to the Next.js HTML shell (already fixed web-side by #7399 for
the no-daemon-origin path).

Reorder the check: report launcher-state-not-eligible first and only
return invalid-payload when the launcher state is actually eligible for
a handoff but the payload file is missing. Payload resolution stays
manifest-driven, so a missing or mismatched manifest keeps failing
closed instead of accepting a guessed executable that the updater never
promoted.

The regression now covers both halves of #6074: the fresh-install
classification, and the packaged startup that actually delivers the web
port the daemon trusts for /api.

Fixes #6074

2026-09-15 06:08:57 +00:00

..

payload-desktop-handoff-6074-regression.test.ts

fix(daemon): defer invalid-payload until launcher state is eligible (#7520)

2026-09-15 06:08:57 +00:00

payload-desktop-handoff.test.ts

reland(sidecar): converge product clients on package boundary (#7636)

2026-09-01 13:22:04 +00:00