v1.2.0-beta.1 shipped — QA checklist + deferred follow-ups #2

New issue

Open

opened 2026-07-06 21:53:22 -04:00 by zgaetano · 1 comment

zgaetano commented

2026-07-06 21:53:22 -04:00

Owner

Shipped in v1.2.0-beta.1 (2026-07-06)

Released: https://forge.wilddragon.net/WildDragonLLC/dragon-iso/releases/tag/v1.2.0-beta.1 (prerelease, MSI attached, SHA256 CEEF41C3…7FB3 verified against the smoke-tested local build).

Fixed on the way to this beta (see CHANGELOG for detail):

Windows build was broken on main — INdiInterop.CreateSender(frameRateN/D) landed with no implementations (CS0535). Linux CI never caught it. Now implemented + covered by 6 new tests; the configured framerate flows settings → IsoPipeline → NdiSender → per-frame frame_rate_N/D stamping.
MSI ProductVersion was hardcoded 1.0.0.0 — MajorUpgrade could never see a newer version. Now derived from $(Version). Note: upgrading from any earlier install may require one manual uninstall (old MSIs all claim 1.0.0.0).
Control surface dead for standard users — http.sys denied the HttpListener prefix. Installer now reserves http://127.0.0.1:9755/ (removed on uninstall). Verified: /, /ui, /participants all 200 as non-admin on a clean install.

⚠ http.sys gotcha (documented in Package.wxs + ControlSurfaceServer)

An idle http://+:9755/ reservation makes http.sys answer 503 to every request to the loopback-bound listener — verified empirically. LAN-reachable mode needs that reservation only while in use; delete it when reverting to loopback-only.

Release infrastructure notes (2026-07-06)

Windows runner was missing — windows-latest had no live runner, so tag-push releases sat "Waiting to run" until Forgejo zombie-failed them (run #150, no logs). Registered wooglin-windows (act_runner v0.6.1, label windows-latest:host, id 5) on the WOOGLIN dev machine; auto-starts at logon via Task Scheduler ("Forgejo Runner (wooglin-windows)", C:\forgejo-runner\).
release.yml asset upload was broken — curl --upload-file PUTs; Forgejo answers 405. Fixed on main (1f6564b) to POST multipart. The v1.2.0-beta.1 release was therefore published via API with the locally built, hash-verified MSI; the next tag push should exercise the full workflow end-to-end on the new runner.

Verified on real hardware (2026-07-06)

Silent MSI install/uninstall, ARP shows 1.2.0, URL ACL add/remove
App startup as standard user (full startup-trace walk)
REST + /ui panel serve correctly (curl, non-admin)
273 unit tests green (Windows slnf, CI filter)
All 9 requires=ndi integration tests green on real NDI 6 runtime (loopback discovery + 1080p pipeline round-trip)

Remaining before GA

Live Teams call QA — real participants, ISO enable/disable, recording, framerate visible correct in downstream switcher (needs a human + a meeting; not automatable here)
Verify the release workflow end-to-end on the new runner at the next tag (v1.2.0-beta.2 or v1.2.0)
OSC surface (UDP 9000) untested in this pass
LAN-reachable mode UX — needs its own + reservation story (settings toggle could offer an elevated one-shot netsh, and must clean up when reverting — see gotcha above)
Deferred item 21 from #1 — TeamsLauncher fallback-chain unit tests (needs a refactor for testability, ~half day)
Two betas of the same x.y.z share an MSI ProductVersion and won't upgrade over each other — bump the patch digit between betas or uninstall first
Housekeeping: API token beta-release-20260706 (scope write:repository) was minted for the release publish and cannot be revoked via CLI on this Forgejo version — delete it in Settings → Applications
Housekeeping: git push --delete on tags hangs against this Forgejo instance (regular pushes fine) — worth investigating server-side

## Shipped in v1.2.0-beta.1 (2026-07-06) **Released:** https://forge.wilddragon.net/WildDragonLLC/dragon-iso/releases/tag/v1.2.0-beta.1 (prerelease, MSI attached, SHA256 `CEEF41C3…7FB3` verified against the smoke-tested local build). Fixed on the way to this beta (see CHANGELOG for detail): 1. **Windows build was broken on main** — `INdiInterop.CreateSender(frameRateN/D)` landed with no implementations (CS0535). Linux CI never caught it. Now implemented + covered by 6 new tests; the configured framerate flows settings → `IsoPipeline` → `NdiSender` → per-frame `frame_rate_N/D` stamping. 2. **MSI ProductVersion was hardcoded 1.0.0.0** — MajorUpgrade could never see a newer version. Now derived from `$(Version)`. **Note:** upgrading from any earlier install may require one manual uninstall (old MSIs all claim 1.0.0.0). 3. **Control surface dead for standard users** — http.sys denied the `HttpListener` prefix. Installer now reserves `http://127.0.0.1:9755/` (removed on uninstall). Verified: `/`, `/ui`, `/participants` all 200 as non-admin on a clean install. ### ⚠ http.sys gotcha (documented in Package.wxs + ControlSurfaceServer) An **idle** `http://+:9755/` reservation makes http.sys answer 503 to every request to the loopback-bound listener — verified empirically. LAN-reachable mode needs that reservation only while in use; delete it when reverting to loopback-only. ## Release infrastructure notes (2026-07-06) - **Windows runner was missing** — `windows-latest` had no live runner, so tag-push releases sat "Waiting to run" until Forgejo zombie-failed them (run #150, no logs). Registered **wooglin-windows** (act_runner v0.6.1, label `windows-latest:host`, id 5) on the WOOGLIN dev machine; auto-starts at logon via Task Scheduler ("Forgejo Runner (wooglin-windows)", `C:\forgejo-runner\`). - **release.yml asset upload was broken** — `curl --upload-file` PUTs; Forgejo answers 405. Fixed on main (`1f6564b`) to POST multipart. The v1.2.0-beta.1 release was therefore published via API with the locally built, hash-verified MSI; the *next* tag push should exercise the full workflow end-to-end on the new runner. ## Verified on real hardware (2026-07-06) - [x] Silent MSI install/uninstall, ARP shows 1.2.0, URL ACL add/remove - [x] App startup as standard user (full startup-trace walk) - [x] REST + `/ui` panel serve correctly (curl, non-admin) - [x] 273 unit tests green (Windows slnf, CI filter) - [x] All 9 `requires=ndi` integration tests green on real NDI 6 runtime (loopback discovery + 1080p pipeline round-trip) ## Remaining before GA - [ ] **Live Teams call QA** — real participants, ISO enable/disable, recording, framerate visible correct in downstream switcher (needs a human + a meeting; not automatable here) - [ ] **Verify the release workflow end-to-end on the new runner** at the next tag (v1.2.0-beta.2 or v1.2.0) - [ ] **OSC surface** (UDP 9000) untested in this pass - [ ] **LAN-reachable mode UX** — needs its own `+` reservation story (settings toggle could offer an elevated one-shot netsh, and must clean up when reverting — see gotcha above) - [ ] **Deferred item 21 from #1** — `TeamsLauncher` fallback-chain unit tests (needs a refactor for testability, ~half day) - [ ] Two betas of the same x.y.z share an MSI ProductVersion and won't upgrade over each other — bump the patch digit between betas or uninstall first - [ ] Housekeeping: API token `beta-release-20260706` (scope write:repository) was minted for the release publish and cannot be revoked via CLI on this Forgejo version — delete it in Settings → Applications - [ ] Housekeeping: `git push --delete` on tags hangs against this Forgejo instance (regular pushes fine) — worth investigating server-side

zgaetano commented

2026-07-29 10:12:22 -04:00

Author

Owner

Repro: control surface never binds when launched non-interactively

Tested on real hardware (zacoffice, hostname UBSTeams2, Windows 11 Pro, .NET 8.0.301, NDI 6 Tools present) — reproduced twice, once before and once after a full reboot.

Steps:

Silent MSI install (msiexec /qn) — clean, exit 0, SHA256 verified against release asset (CEEF41C3…7FB3).
Launch DragonISO.exe as the standard console user via a Scheduled Task (schtasks /create ... /ru <user> /it, interactive-token flag set) rather than a manual double-click.

Result (both runs, identical):

Process starts, confirmed running as <machine>\<user> (not SYSTEM).

Log writes exactly 3 lines and stops:

[INF] [DragonISO.Engine] Diagnostic logs writing to: ...\Logs
[INF] [DragonISO.Engine] DragonISO.App starting up. Build: 1.2.0.0. Process: <pid>.
[INF] [DragonISO.Engine] Config file not found at ...\config.json; using defaults.

No further log lines after 15+ seconds.
Process CPU time stays flat (0:00:05, never climbs) — parked, not crashed, not busy.
MainWindowHandle is 0 (no window created).
Nothing listening on 127.0.0.1:9755 — /, /ui, /participants all connection-refused.
No Windows Application Event Log error/crash for DragonISO.exe (checked Application Error + .NET Runtime providers).

Not yet isolated: whether the hang is in WPF window/dispatcher init (scheduled-task launch may not get a full interactive window station) or in first-run NDI runtime discovery blocking indefinitely. Needs eyes-on debugging (interactive double-click + attached debugger) to pin down — could not safely do this blind over remote command exec.

Why this matters for GA: this is exactly the kind of launch path a Windows service wrapper, RMM tool, or IT-deployed shortcut might use. If the app only works from a literal interactive double-click, that's worth knowing before it goes to customers.

## Repro: control surface never binds when launched non-interactively Tested on real hardware (`zacoffice`, hostname `UBSTeams2`, Windows 11 Pro, .NET 8.0.301, NDI 6 Tools present) — reproduced twice, once before and once after a full reboot. **Steps:** 1. Silent MSI install (`msiexec /qn`) — clean, exit 0, SHA256 verified against release asset (`CEEF41C3…7FB3`). 2. Launch `DragonISO.exe` as the standard console user via a Scheduled Task (`schtasks /create ... /ru <user> /it`, interactive-token flag set) rather than a manual double-click. **Result (both runs, identical):** - Process starts, confirmed running as `<machine>\<user>` (not SYSTEM). - Log writes exactly 3 lines and stops: ``` [INF] [DragonISO.Engine] Diagnostic logs writing to: ...\Logs [INF] [DragonISO.Engine] DragonISO.App starting up. Build: 1.2.0.0. Process: <pid>. [INF] [DragonISO.Engine] Config file not found at ...\config.json; using defaults. ``` - No further log lines after 15+ seconds. - Process CPU time stays flat (0:00:05, never climbs) — parked, not crashed, not busy. - `MainWindowHandle` is 0 (no window created). - Nothing listening on `127.0.0.1:9755` — `/`, `/ui`, `/participants` all connection-refused. - No Windows Application Event Log error/crash for `DragonISO.exe` (checked `Application Error` + `.NET Runtime` providers). **Not yet isolated:** whether the hang is in WPF window/dispatcher init (scheduled-task launch may not get a full interactive window station) or in first-run NDI runtime discovery blocking indefinitely. Needs eyes-on debugging (interactive double-click + attached debugger) to pin down — could not safely do this blind over remote command exec. **Why this matters for GA:** this is exactly the kind of launch path a Windows service wrapper, RMM tool, or IT-deployed shortcut might use. If the app only works from a literal interactive double-click, that's worth knowing before it goes to customers.