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

readiness: count clauses that applied, so a clause's unmet share has a denominator

Abierto
  • ¿Algo no está bien?
#259 0 comentarios 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript
Área
analytics, documentation, observability

Línea de trabajo

Start where render_readiness records verdict and unmet per clause, and see how clauses with skipped set are handled, using readiness.require[] as the source. Add an applied series per (contract, clause) in metrics.js and document it in METRICS.md. Then reword the threshold comment in packages/browser/src/readinessDrift.ts. Done when a test shows unmet / applied for a guarded clause and the two docs agree.

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

Descripción

enhancement

Problem

A clause's failure share is not readable from the plugin's metrics, and one browser comment understates how often a healthy clause fails.

  1. No denominator per clause. render_readiness records verdict once per governed variant and unmet once per failing clause. A clause that a guard skipped is not counted at all. So unmet for a clause can only be read against all the contract's renders, not against the renders where that clause applied. The fleet's drift detector (packages/browser/src/readinessDrift.ts) measures the other way: failures over applicable renders. The two disagree whenever a clause is guarded.
  2. The drift threshold comment is wrong for guarded clauses. ReadinessDriftPolicy.threshold says healthy clauses fail on "a few percent of renders". A clause guarded on a third-party slot can fail on about a quarter of the renders it applies to and still be healthy, because the slot mounts with nothing to show.

Evidence (2026-10-16, one production cluster)

  • One product contract had a review-summary clause guarded on the slot's presence. The slot mounts on products with enough ratings. On about 25% of those, the vendor has no summary, so the clause can never hold. The stored pages are correct.
  • Plugin: 159,162 verdicts, 4,428 unsatisfied, with that clause unmet on 3,001. The share of renders where it applied isn't recoverable from render_readiness.
  • Fleet: up to 7 of 60 workers latched that clause in readinessFailing for hours. They measured about 40% failure where the slot applied, against the 50% threshold and 25% recovery.

The clause itself is being fixed in the consumer's contract; that is not this issue.

Proposed

  • Plugin: record, per clause, whether it applied: for example render_readiness series applied (contract, clause) from readiness.require[] where !skipped. unmet / applied is then the clause's failure share, on the same denominator as the drift detector. Document it in metrics.js and METRICS.md.
  • Browser: reword the threshold doc. A guarded clause's legitimate failure share depends on how often its guard's slot is empty; don't promise "a few percent".

Done when

  • unmet / applied per clause is readable from analytics, with a test.
  • The METRICS.md entry and the readinessDrift.ts comment match.
Lenguaje dominante
JavaScript
Estrellas
0
Forks
0
Merge medio
3 h 1 min
PR fusionados (30 d)
70

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 HarperFast/prerender-plugin

Todos los issues de HarperFast/prerender-plugin

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.