fix(gateway): Windows compatibility fixes - #8180
Conversation
d8f86cb to
f7cc10e
Compare
410d0ae to
b8d3aef
Compare
|
Thanks for this — appreciate the work. We're closing the entire cluster of open native-Windows PRs (44 of them spanning installer, terminal routing, file ops, gateway PID handling, encoding, docs, and more) because the surface area needs a designed, consolidated approach rather than piecemeal merges. Cherry-picking individual fixes keeps leaving inconsistencies and we'd rather land Windows support properly, in one coherent pass.\n\nYour PR is catalogued in our internal Windows support plan. When we pick this back up (soon), we'll mine every PR in the cluster for its fix shape and credit all contributors whose work informs the final patch via lines. Watch for the consolidating PR and feel free to chime in with context on the specific failure mode you were hitting.\n\nClosing for now, not as a rejection of the fix — just queueing it for the designed rollout. Thanks again. |
What does this PR do?
This PR narrows the Windows gateway compatibility fix to gateway-specific issues only.
It fixes two Windows failure modes:
gateway/status.pynow treatsOSErrorfromos.kill(pid, 0)as a stale-process signal, matching Windows behavior where process existence checks can raiseOSErrorinstead ofProcessLookupError.gateway/run.pynow installs a temporary UTF-8 stderr handler during early startup on Windows so gateway startup logs do not fail under non-UTF-8 console encodings. The temporary handler is removed immediately aftersetup_logging()runs, so it does not leave an extra console handler behind.The previous
memory_toolWindows fix has been split out into separate PR #8563 so this PR stays focused on gateway behavior.Related Issue
No linked issue.
Type of Change
Changes Made
OSErrorhandling togateway/status.pyprocess liveness checksgateway/run.pyfor early startup logs on Windowssetup_logging()so it does not persist into normal runtime loggingOSErrorhandling and bootstrap handler cleanupmemory_toolchange from this PR and keep it in PR fix(memory): support Windows memory file locking #8563 insteadHow to Test
python -m pytest tests/gateway/test_status.py::TestGatewayPidState::test_get_running_pid_treats_oserror_as_stale -q -n 0python -m pytest tests/gateway/test_status.py::TestScopedLocks::test_acquire_scoped_lock_replaces_oserror_record -q -n 0python -m pytest tests/gateway/test_runner_startup_failures.py::test_start_gateway_removes_bootstrap_stderr_handler_after_setup -q -n 0python -m pytest tests/gateway/test_runner_startup_failures.py::test_start_gateway_verbosity_imports_redacting_formatter -q -n 0python -m pytest tests/gateway/test_runner_startup_failures.py::test_start_gateway_replace_force_uses_terminate_pid -q -n 0python -m pytest tests/gateway/test_status.py::TestScopedLocks::test_acquire_scoped_lock_replaces_stale_record -q -n 0Checklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests passDocumentation & Housekeeping
docs/, docstrings) — or N/Acli-config.yaml.exampleif I added/changed config keys — or N/ACONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — or N/AScreenshots / Logs
tests/gateway/test_status.py::TestGatewayPidState::test_get_running_pid_treats_oserror_as_stale-> passedtests/gateway/test_status.py::TestScopedLocks::test_acquire_scoped_lock_replaces_oserror_record-> passedtests/gateway/test_runner_startup_failures.py::test_start_gateway_removes_bootstrap_stderr_handler_after_setup-> passedtests/gateway/test_runner_startup_failures.py::test_start_gateway_verbosity_imports_redacting_formatter-> passedtests/gateway/test_runner_startup_failures.py::test_start_gateway_replace_force_uses_terminate_pid-> passedtests/gateway/test_status.py::TestScopedLocks::test_acquire_scoped_lock_replaces_stale_record-> passedKeyboardInterrupt/ asyncio cleanup), so the validated results above are from focused test invocations