feat: Limit concurrent procedure execution in HTTP batches

Abierto
  • ¿Algo no está bien?
#7,734 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
api, backend

Línea de trabajo

Start by locating the HTTP batch execution path that uses info.calls.map(async ...), then read the existing server options and tests for ordinary and streaming batches. Add coverage for peak concurrency, default behavior, result ordering, per-call errors, and cancellation with queued calls; done means the opt-in limit applies per batch and streaming behavior stays unchanged.

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

Descripción

Describe the feature you'd like to request

The server currently starts all procedures in an HTTP batch concurrently through info.calls.map(async ...). The existing maxBatchSize option limits the number of procedures in a batch, but not how many can execute at once.

For example, a batch of 20 database queries can start all 20 concurrently, even when the application would benefit from limiting that to four at a time.

It would be useful to have an opt-in concurrency limit for HTTP batches, so applications can control how many procedures run simultaneously without changing the default behavior.

Describe the solution you'd like to see

Add a configurable concurrency limit for ordinary, non-streaming HTTP batches. For example, a server-side option could allow a batch to run at most four procedures at a time, with the remaining calls waiting until a slot becomes available.

The limit should apply per batch, not across all incoming requests. Existing behavior should remain unchanged when the option isn't set.

The implementation should preserve result indices and existing per-call error handling. If a request is cancelled, queued procedures must not start, and running procedures should receive cancellation through the existing AbortSignal.

For the initial implementation, streaming batches can remain unchanged, since long-lived procedures need different concurrency semantics.

Tests should cover peak concurrency, default behavior, out-of-order completion, per-call errors, and cancellation while calls are waiting in the queue.

Describe alternate solutions

Increasing or decreasing maxBatchSize only changes how many calls can be included in a batch; it doesn't directly control concurrent execution.

Applications can also limit concurrency in individual procedures or rely on database connection pools, but these approaches either require custom logic in application code or limit a different resource. A per-batch limit would provide more direct control over how much work a single HTTP request can start at once.

Additional information

This should be an opt-in change limited to server-side execution of ordinary HTTP batches. It shouldn't introduce a global concurrency limit or change streaming behavior.

The main goal is to let applications protect downstream services from bursts of concurrent work while preserving tRPC's existing batching, response ordering, and error semantics.

👨‍👧‍👦 Contributing
  • 🙋‍♂️ Yes, I'd be down to file a PR implementing this feature!
Lenguaje dominante
TypeScript
Estrellas
40.8k
Forks
1.7k
Merge medio
1 d 17 min
PR fusionados (30 d)
184

Preparar el entorno

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 trpc/trpc

Todos los issues de trpc/trpc

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.