ColtenOuO opened a new pull request, #72116:
URL: https://github.com/apache/airflow/pull/72116
### Summary
`CommChannel.connect()` (`ts-sdk/src/coordinator/comm-channel.ts`) opens the
comm TCP socket and then awaits `channel.greeting.promise` — the supervisor's
first frame (`StartupDetails` or `DagFileParseRequest`) — with no timeout of
its own. Once the TCP connection succeeds, nothing bounds how long the Node
coordinator process will wait for that first frame: if the socket stays open
but the supervisor never writes the greeting (a wedged or misbehaving
supervisor, a stuck process on the Python side, a protocol bug), `connect()`
never resolves and never rejects, and the coordinator subprocess hangs
indefinitely with no way to recover on its own.
This is inconsistent with the rest of the same class: every subsequent
`request()` call on the channel already times out after
`COORDINATOR_REQUEST_TIMEOUT_MS` (30 seconds,
`ts-sdk/src/coordinator/comm-channel.ts:54`) via `Deferred.rejectAfter()`, and
`sendResponse()` supports an equivalent optional timeout that destroys the
socket when a terminal write wedges. The greeting wait — which happens once, at
startup, before any request/response traffic — was the one gap left uncovered.
### Change
- Added `ConnectOptions` (`{ timeoutMs?: number }`) and a third parameter on
`CommChannel.connect()`.
- `connect()` now arms `channel.greeting.rejectAfter(timeoutMs, ...)` right
after opening the socket, defaulting `timeoutMs` to the existing
`COORDINATOR_REQUEST_TIMEOUT_MS` (30s) for consistency with the rest of the
channel. This reuses the same self-clearing-timer `Deferred` mechanism already
used by `request()` and `sendResponse()` — no new timer bookkeeping.
- On timeout, the socket is destroyed (`sock.destroy(err)`) with a
descriptive error, mirroring the existing `sendResponse` timeout pattern, so a
wedged supervisor connection is actually torn down instead of left dangling.
- A normal greeting arrival still resolves `connect()` immediately and
clears the timer, so there's no behavior change on the working path.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Sonnet 5)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]