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

Open
#189 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript

Research direction

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.

Written by the indexing model from the issue text.

Description

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

Dominant language
JavaScript
Stars
0
Forks
0
Avg merge
9h 10m
Merged PRs (30d)
56

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from HarperFast/prerender-plugin

All issues in HarperFast/prerender-plugin

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.