[tang-vu]

Summary

Let Windows PowerShell 5.1 ods.ps1 repair voice continue to cache verification after its expected native curl timeout. Scope the native invocation's error preference and restore it in finally, preserving existing exit-code decisions and diagnostics. Curl exit 0/28 permits cache verification; other exits warn and return false.

Refs #3003. Other native-stderr sites remain outside this voice-repair outcome.

Why this matters

Speaches can continue downloading after curl's bounded request expires. Redirected native stderr under PowerShell 5.1's Stop instead throws NativeCommandError, so the repair command aborts before checking the model cache. The fix preserves the existing 900-second cache-wait handoff and accepted exit codes.

Overlap check

Open/closed native-stderr, Windows voice-repair and curl-timeout searches covered closed #3016/#3253. #7842 concerns lifecycle invocation policy. Current main's Compose recovery #7887 remains intact. No active equivalent request-boundary fix was identified.

AI Assistance

This fix was developed collaboratively by tang-vu and Codex. I led the contribution, defined its goals, scope and quality requirements, and provided the development and validation environment. Codex assisted with implementation, analysis, automated testing and static review. The validation section documents the checks performed and remaining release gates.

Release Lane / Changed Surface

• Mainline targeting main.
• Windows CLI voice-repair request boundary and native regression; high risk under the lifecycle map, with a narrow behavioral scope.

Current candidate and validation

Rebased on c99f52822f2c37813fd880004f964ca83dfc5a35; current candidate c78c025bd. Original head f5dd2617cf00da53c3a0bbfa9310775513667c4d is retained under a local archive ref. Stable patch-ID comparison proves production and test contents are equivalent. The conflict was only additive workflow placement; both current-main Compose recovery steps remain. The STT step now sits beside Whisper contracts to avoid a repeated conflict with #7877.

Agent-executed validation on the rebased candidate:

• Windows PowerShell 5.1 tests/contracts/test-windows-stt-trigger.ps1: all five native-curl/repair checks pass for exit 28/0/22/7, diagnostics, restored preference and the real repair caller's cache-wait handoff.
• The original regression fails on the old base with NativeCommandError at exit 28.
• Commit identity, git diff --check and Gitleaks 8.30.1 on the complete added range pass.
• Independent range-diff/workflow review found no blocker. Pairwise merge simulation with rebased fix(cli): authenticate native chat and fail when no answer is returned #7877 and the opt-in desktop-preview branch succeeds.
• The regression executes in the Windows PowerShell 5.1 workflow step. Hosted checks are tracked on this exact head.

An additional local PowerShell 7 attempt cannot compile this existing fixture because Add-Type -OutputType ConsoleApplication is unsupported there. This is a PS5.1-targeted native-stderr fixture, and no successful PS7 execution is claimed. The production patch is unchanged by this maintenance.

The original fixture follow-up still explicitly returns zero after cleanup, avoiding GitHub's wrapper inheriting its expected native exit 28. Earlier failed CI evidence is retained.

Operational limits / rollback

The real request helper and repair caller run with a fixture-owned native curl executable. Network, Docker and host-mutating boundaries are replaced. No live Whisper download, clean install, installed Portal/model or release-fleet acceptance is claimed. Independent human release review remains required. Rollback is a revert; no persisted format changes.

The earlier ten-scope combined receipt is historical evidence at https://github.com/tang-vu/DreamServer/tree/699cfb4de90adc6efb17c2497fc3396b58e75a86; its successful checks and recorded exact-base fixture failures do not substitute for current-head CI or release acceptance.

Current hosted CI diagnostic (2026-10-22)

The unchanged Portal project job failed before execution because its real Docker memory probe timed out after 5 seconds with no stdout/stderr (engine-info-unavailable). The project controller, regression test and workflow blobs are identical to current main and to #7877, where this same job passed. Failure log: https://github.com/Osmantic/ODS/actions/runs/39725711368/job/119648996020. Rerunning failed jobs was denied with HTTP 403 (Must have admin rights to Repository). A maintainer rerun remains needed; this is not reported as a green gate and no retry/timeout policy was changed.

Queue maintenance (2026-10-23)

Current head remains c78c025bdb30e621c9f87cdfb723210b6fd77ade, conflict-free. Current hosted result: 72 successful checks, one failed, zero pending. The unchanged managed-project failure still records a five-second Docker-info timeout (engine-info-unavailable) before project execution; failure evidence.

A fresh request to rerun only failed jobs was rejected with HTTP 403 (Resource not accessible by integration). A maintainer rerun and investigation if the failure repeats are still needed. No STT behavior or unrelated Docker timeout policy was changed to trigger another run.

Current-main maintenance (2026-10-24)

Final candidate c141a38463c7a18fdc5717f5fdf818e1fafa48e7. Current upstream main fce1a2281343cd9de1ca0622b4bbf28f3469523e merged normally without conflicts. Diff against main remains the three Windows STT/fixture/workflow files. The actual STT contract passes Windows PowerShell 5.1; identity, diff and Gitleaks pass. The existing fixture intentionally executes in Windows PowerShell 5.1 CI. An optional PowerShell 7 attempt stops before product assertions because its Add-Type ConsoleApplication fixture compiler is unsupported there; that attempt is not claimed as a product failure or successful PS7 qualification. The previous-head managed-project CI failure recorded a real Docker engine-info timeout at five seconds before project execution, unrelated to STT. An upstream job rerun requires repository administrator rights (HTTP403); current-head CI is followed separately. No unrelated project code was changed.

These command checks were agent-executed. tang-vu leads this contribution and its quality requirements, collaborating with Codex on maintenance and validation. Prior evidence above applies to its named heads; hosted checks and release acceptance for this head remain separate.

[Lightheartdevs]

Thanks for fixing the native-curl timeout boundary so voice repair can reach cache verification on Windows PowerShell 5.1.

Advisory status: needs human decision

The scoped error preference and finally restoration look sound. I reproduced all five native-curl/repair checks, including exit 28 reaching the 900-second cache-wait handoff.

The remaining decision is the failed managed-project check, already documented in the PR. Its failure log shows ods/extensions/services/pixel-agent/tests/test_project_controller.py:260 failing after a five-second Docker-info timeout (engine-info-unavailable, before project execution). This does not establish an STT regression. The quickest path to merge is a maintainer rerun of that job and triage if it repeats; no STT code change is indicated by this evidence.

What I checked:

• Current main architecture/contribution guidance, all three changed files, surrounding trigger/repair code, and CI wiring.
• powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File ods/tests/contracts/test-windows-stt-trigger.ps1: all five checks passed on the reviewed head.
• Hosted checks: 72 successful, one failed at inspection. No live model download or installed-system acceptance was performed.