[quality] bundle fake answers unrouted requests with a plain 404; the harness should assert on unexpected traffic outside application fallbacks

Cerrado
  • ¿Algo no está bien?
#568 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #569 de @hivecommons-hive — fusionado

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
48/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
graphql, typescript
Área
backend, developer-experience, testing

Línea de trabajo

Start with __tests__/bundle/fakeGithub.ts and its reset and unmatched-request handling, then inspect src/utils/mergeQueue.ts to understand why unexpected 404 responses are currently swallowed. Add the opt-in unmatched-request allowance and assertion contract, and pin it with a harness-only test. Update the named OWNERS bundle suites and verify the focused bundle tests; avoid broader suite adoption, which is explicitly out of scope.

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

Descripción

agent/quality needs-kind stage/040-covered-by-pr testing

Finding

Child of #554 (P1 "Strengthen assertions and the test harness", second checkbox): __tests__/bundle/fakeGithub.ts records requests no route matched but answers them with a normal-looking 404, so each scenario is left to notice traffic it never modelled. Application fallbacks hide the miss: src/utils/mergeQueue.ts queueState swallows any error (including that 404) into a once-per-run warning and a direct merge, which is the #518 pattern.

Measured on main at e3119ad by instrumenting the fake's 404 arm during vitest run __tests__/bundle (86 files, 528 tests): 3,029 unmatched requests. ~2,800 are the configuration loader's probes and 175 the OWNERS tree probe, both intentional. The residue is 25 unmatched POST /graphql (tide's merge queue read, in 11 files that never route it) and ~20 membership/collaborator/OWNERS reads whose 404 is the point of the scenario. None of those is asserted as intentional anywhere; a forgotten route and a deliberate miss look identical.

Recommendation

  • Keep the unmatched requests apart in the fake and let a scenario declare the misses it relies on (allowUnmatched), with the configuration loader's probes always allowed.
  • Give the harness an assertion that fails a scenario on the rest (assertNoUnexpectedRequests), callable from afterEach ahead of reset.
  • Pin that contract with a harness-only test (plain fetches, no bundle run).
  • Adopt it in the OWNERS bundle suites whose merge queue read was unrouted (ownersParseArms.test.ts, ownersProbeArms.test.ts), answering that read through mergeQueueFallback as lgtmBindingArms/lgtmRemovalNoopArms already do.

Wider adoption across the other bundle files that leave POST /graphql unrouted (approveMembershipArms, cronLgtmFailureArms, ownersTreeLoadArms, ownersFilters, approveEvaluationArms, blunderbussArms, blunderbussDelay) is deliberately not part of this issue: the blunderbuss files are occupied by open hold PRs (#559, #561, #562, #567), and each remaining file is a one-line beforeEach/afterEach change that can follow once the harness is in.

Decision taken by hive: additive API on the fake, opt-in per file, loader probes allowed by default. Making reset() assert for every file would fail ~20 suites at once and is not backward compatible.

Priority

  • Impact: high (unmodelled traffic currently passes silently in bundle scenarios)
  • Effort: low

Filed by quality agent (hold-gated mode)

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: 6faa951

— hive: agent=quality backend=copilot model=claude-fable-5.1

Lenguaje dominante
TypeScript
Estrellas
132
Forks
24
Merge medio
1 d 6 h
PR fusionados (30 d)
240

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 cncf/prow-github-actions

Todos los issues de cncf/prow-github-actions

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.