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

queue: no test executes the worker's raw SQL, so a type-resolution error would ship green

Abierto
  • ¿Algo no está bien?
#247 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
postgresql, typescript
Área
backend, databases, testing

Línea de trabajo

Comienza con queue.test.ts y worker-concurrency.test.ts; después, inspecciona el servicio de CI postgres:18 existente y la configuración de la base de datos migrada. Añade un archivo de pruebas respaldado por Postgres que cubra la ejecución de SQL sin procesar, los predicados de reclaim, los bloqueos legacy, las actualizaciones de DEAD_LETTER frente a PENDING y el plan de índices indicado; el trabajo estará terminado cuando estos comportamientos y los riesgos de resolución de tipos se ejerciten sin mocks de Prisma.

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

Descripción

roadmap: now

Raised repeatedly during the #224 review rounds, and it is the structural limit of the current approach rather than anything wrong with the tests that exist.

The gap

Every claim and reclaim assertion in queue.test.ts and worker-concurrency.test.ts is a substring match against mock.calls[0][0].join(' ') — the template literal's static fragments. The tests mock prisma, so CI never executes the SQL either.

Unverified anywhere, and all of it is load-bearing:

  • gen_random_uuid()::text
  • (jsonb ->> "Job".type)::double precision — the per-type timeout lookup
  • <param> * INTERVAL '1 millisecond' operator resolution against Prisma's parameter typing
  • LEAST(<float8>, $n) with a Prisma-typed integer parameter — a classic "could not determine data type of parameter" shape
  • POWER, random(), left(job.error, 200), and the string concatenation on the error column
  • type unification across the CASE arms
  • UPDATE ... RETURNING "claimToken" semantics
  • whether the planner actually uses Job_status_lockUntil_idx — a property asserted as fact in both schema.prisma and the migration, and only provable by EXPLAIN

Why it is worth doing now

A type-resolution error in reclaimStaleJobs fails on the first poll of every replica, with CI fully green — the sweep is the first statement of every poll. That is a fleet-wide failure that no gate we have can catch.

Behavioural gaps that fall out of the same absence:

  • The reclaim predicate has no behavioural test. The premise of #224 is "reclaim on the deadline the claiming worker recorded", and no test asserts which rows that predicate actually selects. Wanted: lockUntil = now + 120s is left alone by a worker whose defaultTimeoutMs is 5s; lockUntil = now - 1s is left alone (inside the grace); lockUntil = now - 31s is reclaimed.
  • The legacy arm is untested behaviourally — lockUntil IS NULL with lockedAt 20 min ago reclaims, 5 min ago does not.
  • The DEAD_LETTER vs PENDING branch is untested — attempts + 1 >= maxAttempts drives three different columns. A row at attempts=4, maxAttempts=5 must land DEAD_LETTER with completedAt set and runAt untouched; at attempts=0, PENDING with a future runAt and completedAt NULL.

Shape

The repo already runs a postgres:18 service in CI. One Postgres-backed test file against a migrated database would cover every item above at once, and queue.test.ts's own header has said integration tests "should be added separately" since it was written — with no owner and no link. This is that link.

Lenguaje dominante
TypeScript
Estrellas
10
Forks
4
Merge medio
4 d 2 h
PR fusionados (30 d)
7

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 CopilotKit/outpost

Todos los issues de CopilotKit/outpost

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.