Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#189 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript
Lĩnh vực
analytics, frontend, observability

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
JavaScript
Star
0
Fork
0
Merge trung bình
8 giờ 25 phút
Pull request đã merge (30 ngày)
71

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của HarperFast/prerender-plugin

Tất cả issue của HarperFast/prerender-plugin

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.