Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

ChildProcess: support bidirectional (duplex) additional file descriptors

Chiusa
  • Qualcosa non va?
#8,902 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #8905 di @effect-bot — integrata

Valutazione

Difficoltà
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
node.js, typescript
Ambito
backend

Direzione di ricerca

Start from the ChildProcessOptions.additionalFds type and NodeChildProcessSpawner implementation in the platform-node-shared package. Add a duplex variant to AdditionalFdConfig that provides both a Stream and a Sink for the same descriptor, then extend ChildProcessHandle with a getDuplexFd method. Verify the change with the existing child process test suite.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What is the problem this feature would solve?

ChildProcessOptions.additionalFds only lets you configure each extra descriptor in one direction:

type AdditionalFdConfig =
  | { readonly type: "input"; readonly stream?: Stream<Uint8Array, PlatformError> }
  | { readonly type: "output"; readonly sink?: Sink<Uint8Array, Uint8Array, never, PlatformError> }

The Node spawner (@effect/platform-node-shared/NodeChildProcessSpawner) sets each configured fd to "pipe". For fd ≥ 3, Node backs that with a bidirectional Unix domain socket. Effect then exposes it either as a Sink (getInputFd) or as a Stream (getOutputFd), never both. And because additionalFds is keyed by fd name, one descriptor can't be declared as both input and output.

So there's no way to run a request/response protocol between parent and child over a single inherited socket, e.g. a sidecar speaking a framed protocol on fd 3. Code that needs this has to call node:child_process spawn with stdio: [..., "pipe"] directly and drive child.stdio[3] itself. That means giving up ChildProcessSpawner and doing manual lifecycle, exit and error handling plus raw event listeners. The workaround of using two descriptors (fd 3 in, fd 4 out) changes the child's protocol contract and isn't always an option.

What is the feature you are proposing to solve the problem?

Add a duplex variant to AdditionalFdConfig, for example:

additionalFds: { fd3: { type: "duplex" } }

ChildProcessHandle would then expose both directions for that fd, e.g. a getDuplexFd(fd) that returns { stream, sink }. Alternatively, getInputFd and getOutputFd could both work on the same "duplex" descriptor.

What alternatives have you considered?

  • Using node:child_process spawn directly and driving child.stdio[3] manually, which is what we do today.
  • Splitting the protocol across two unidirectional descriptors. This needs a change on the child side and doesn't match socket semantics such as half-close and shutdown.

Version: [email protected], @effect/[email protected].

Lingua principale
TypeScript
Stelle
16.7k
Fork
808
Merge medio
9h 36m
PR unite (30g)
577

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Effect-TS/effect

Tutte le issue di Effect-TS/effect

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.