Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
  • 哪裡不對？
#259 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
3/5
預估耗時
1-2 天
新手友好度
42/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
javascript
領域
analytics, documentation, observability

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

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.
主要語言
JavaScript
星號
0
分支
0
平均合併
3 小時 1 分鐘
30 天內合併 PR
70

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

HarperFast/prerender-plugin 的其他 Issue

查看 HarperFast/prerender-plugin 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。