fix: validate Responses proxy liveness before reuse - #134
Open
sylvesterkaczmarek wants to merge 3 commits into
Open
fix: validate Responses proxy liveness before reuse#134sylvesterkaczmarek wants to merge 3 commits into
sylvesterkaczmarek wants to merge 3 commits into
Conversation
|
All contributors have signed the CLA ✍️ ✅ |
Author
|
I have read the CLA Document and I hereby sign the CLA |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Verify that an existing Responses API proxy is actually alive before reusing its server-info file.
Fixes #133.
Problem
codex-actioncurrently treats a non-empty server-info JSON file as proof that the proxy is still running:The proxy writes
{ "port": ..., "pid": ... }once at startup. If that process later exits unexpectedly, the file can remain behind.A subsequent action invocation using the same run/Codex-home path then:
Start Responses API proxy;The resulting connection failure occurs well after the action has incorrectly reported that the proxy was reusable.
Fix
Replace the file-size-only status check with a dependency-free Node helper that validates the complete reusable state:
pidis a positive integer;portis an integer in the valid TCP port range;process.kill(pid, 0);EPERMis treated as existing);Only when all checks pass does the helper emit:
Missing, empty, malformed, dead-process, or closed-port state is reported as
false. Stale non-empty metadata is removed so the existing proxy-start step can create a fresh server-info file.The cleanup path first removes files normally and, on Unix, falls back to non-interactive
sudo rmfor server-info files that the action previously hardened to root ownership.Why check both PID and port
A process check alone is insufficient because a live process does not prove that the expected proxy listener is still available. A port check alone is also insufficient because a port can be reused by another process. Requiring both substantially narrows false reuse while keeping the check local and credential-free.
The helper does not send an HTTP request to the proxy, so it cannot accidentally trigger
/shutdownor send application data.Regression coverage
Added direct Node-stdlib tests for four states:
false;false;false;trueand preserve the file.The live case uses an ephemeral
net.Server, so it exercises the same TCP-connect path as production without depending on the Codex proxy package or network access.Scope
This deliberately does not change proxy startup, API-key handling, upstream endpoint configuration, server-info format, Codex configuration, or the proxy package itself.
There are no changes under
src/, so the checked-indist/main.jsbundle remains valid and does not need regeneration.Validation
main(c385816875cc2fc8e033ed9d1cba96f8c331210e)action.yml, the new helper, and its focused testFull repository validation is left to the repository's GitHub Actions checks.
Risk
Low. Existing healthy proxies continue to be reused. The behavior changes only when the previously trusted server-info file cannot demonstrate a live process and listener, in which case starting a new proxy is safer than configuring Codex against stale state.