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

Run the fqm-execution call in a worker thread — the nightly's 21-second stalls are inside a loop we do not own

Cerrado
  • ¿Algo no está bien?
#604 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
backend, performance

Línea de trabajo

Read ADR-085, wiring/executor-router.ts, wiring/official-executor-adapter.ts, and packages/official-executor/src/index.ts to trace the evaluateBatch path into fqm-execution. Run the existing nightly instrumentation and compare value-set cache transfer, warning and retrieve-signal behavior, and worker failure handling. Done means a documented decision supported by measurements and defined semantics for these open questions.

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

Descripción

#563 is diagnosed and half-answered. This is the other half, and it needs a decision rather than a
patch.

What #588 measured, and what #602-era work confirmed

evaluateBatch is 93.9% of a 90-minute nightly — ~21 s per 500-subject call, bundles 0.33%.
During that window GET /api/version, which opens no database connection and therefore cannot be
waiting for one, answered in 13.8–22.0 s against 0.2 s quiet.

The mechanism is now nailed down. Measured on the dev host, 60 iterations x 42 ms of CPU with a local
HTTP server probed concurrently:

yield between iterations requests served worst latency
none 1 2,534 ms
queueMicrotask 1 2,523 ms
setImmediate 31 43.5 ms
setTimeout(0) 105 85.6 ms

A microtask yield changes nothing, because Node drains the whole microtask queue before reaching the
poll phase. Only a macrotask lets a pending request be served.

Why that does not finish the job

ADR-085 d1 applies the macrotask yield to the loops we own. The pilot's nightly is not one of them.
deps.engine.evaluateBatch resolves through wiring/executor-router.ts to runBatch
(wiring/official-executor-adapter.ts) to calculateOfficialWithSignal
(packages/official-executor/src/index.ts), which is:

const output = await calculate(input.bundle, input.patientBundles, options, input.valueSetCache);

One call into fqm-execution with every bundle in the chunk. We do not own that loop. All six of
the pilot's measures are official-routed (ADR-078), so this is ~the whole of its nightly.

WORKWELL_RUN_CHUNK_SIZE divides the stall — a chunk boundary is a real database write and therefore
a real yield point — but it cannot remove it, and it buys shorter stalls with more round trips.

The proposal

Run the fqm-execution call in a worker thread, so a CPU-bound third-party library stops
occupying the event loop that serves requests.

  • fqm-execution is Node-only already, so the @mieweb/cloud portability constraint that shaped
    ADR-085 d1 does not bind packages/official-executor.
  • The call's inputs (measure bundle, patient bundles, period, value-set cache) and its output are
    plain JSON, so they are structured-cloneable — no shared handles to arrange.
  • The worker can be pooled or spawned per chunk; per chunk is simpler and the setup cost is amortised
    over ~21 s of work.

Open questions for whoever picks this up:

  1. Does the value-set cache survive the boundary cheaply? It is the one input that could be large,
    and copying it per chunk would show up in batchMs immediately (which is the nice part — the
    instrumentation to check already exists).
  2. What happens to onWarning and the retrieve signal? Both cross back today as ordinary returns;
    a warning currently emitted mid-call would need to be collected and returned instead.
  3. Failure semantics. A worker crash must fail the chunk the way a thrown error does now, not
    leave the run RUNNING — the same rule the chunked persist path already follows.
Not blocking anything today

The nightly runs 12:09–13:40 UTC, which is 02:09 Hawaii, and #590 removed the user-facing trap
(a MEASURE run that 504'd and invited a retry that also ran). This is about the sandbox being
usable while a run is in flight, and about the number not getting worse as the corpus grows.

Related: #563 (the measurement), #588 (the instrumentation), #590, ADR-085.

Lenguaje dominante
TypeScript
Estrellas
0
Forks
0
Merge medio
4 h 5 min
PR fusionados (30 d)
126

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 Taleef7/workwell

Todos los issues de Taleef7/workwell

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.