Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Console: chart `render_readiness` — a Readiness panel for the report-only window and the arming decision

Aperta
#189 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript

Direzione di ricerca

Start with packages/console/test/adminAssets.test.js and trace the console analytics entry point for /prerender_console/analytics. Compare the render_readiness rows with packages/plugin/METRICS.md and the raw /prerender_admin/analytics response. Done means a console Readiness panel covers verdict, unmet, satisfied_ms, shortfall, and rebaseline with the stated denominators and percentile semantics.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Plugin v0.79.0 added the render_readiness metric (series verdict, unmet, shortfall, rebaseline, satisfied_ms; see packages/plugin/METRICS.md). The console does not read any of it. The coverage guard in packages/console/test/adminAssets.test.js caught this — it fails on main as of 0.79.0 — and is being waived with a pointer here so the plugin fix train is not blocked on a console release.

What the panel needs to answer

This metric exists to make two decisions, in order:

  1. Is the fleet storing incomplete renders? verdict by contract: satisfied vs unsatisfied share. unmet by clause: which assertion fails — one clause failing across every render of a page type is a rotted contract (template changed), not a slow fleet.
  2. Can the contracts be armed, and with what timeout? satisfied_ms p50 / p95 / p99 per contract against that contract's configured timeoutMs. If p95 approaches the timeout, arming would abandon the contract under load and the optimisation is quietly gone.

Plus the content-loss signal once armed: shortfall by observation and rebaseline counts, per contract.

Readout semantics to get right

  • verdict is one per governed device variant, so a two-device job emits two. Shares should be read against render.time_ms (one per rendered device), not render.outcome (one per posted result).
  • satisfied_ms is a value series with mean/median/p95 from the plugin analytics endpoint (p99/p999 only from Harper's get_analytics). Unsatisfied renders contribute nothing to it, by design.
  • unmet does not sum to renders — read it against the unsatisfied count. A row where every clause of a contract is unmet is an execution context lost mid-settle (client-side navigation), not rot.
  • shortfall compares a page (URL + device) against its own history; it is silent on a first render and after a rebaseline.

Where it is read today

Raw only: GET /prerender_admin/analytics?range=<ms> → .series[] | select(.metric == "render_readiness") per node; the console's /prerender_console/analytics already returns the rows (keepRow keeps every catalogued metric) — there is just no panel.

🤖 Generated with Claude Code

Lingua principale
JavaScript
Stelle
0
Fork
0
Merge medio
8h 48m
PR unite (30g)
58

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/prerender-plugin

Tutte le issue di HarperFast/prerender-plugin

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.