Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

ChildProcess: support bidirectional (duplex) additional file descriptors

Cerrado
  • ¿Algo no está bien?
#8,902 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #8905 de @effect-bot — fusionado

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
node.js, typescript
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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].

Lenguaje dominante
TypeScript
Estrellas
16.7k
Forks
808
Merge medio
9 h 39 min
PR fusionados (30 d)
703

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Effect-TS/effect

Todos los issues de Effect-TS/effect

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.