diff --git a/kinds/wordpress-plugin/review-profile.md b/kinds/wordpress-plugin/review-profile.md index 2599c05..d5252c7 100644 --- a/kinds/wordpress-plugin/review-profile.md +++ b/kinds/wordpress-plugin/review-profile.md @@ -107,3 +107,6 @@ reading can find. ## Lessons learned + +- When a change adds a retry, a scheduled fallback event, a failure callback or a row that holds billed remote state (an unfinished multipart upload), check every path that ends the work, fails it or deletes the row: each must clear the event, run the callback or abort the remote state, including a 200 with an error body and a transport error. +- When a header, limit or option must apply to every request or upload path, check that a test covers each variant (single, multipart, copy, resumed, pooled; `wp_remote` and curl), not only the simplest one. diff --git a/review-profiles/general.md b/review-profiles/general.md index 96904f2..98ca4f9 100644 --- a/review-profiles/general.md +++ b/review-profiles/general.md @@ -124,3 +124,5 @@ in the last 7 days; a human merges them. pull request. - When a pull request says it moves to a new version of a pinned workflow, check that the pin itself moved (the `uses:` SHA and every `central-ref`-style default), not only the comments and docs. Docs that describe a safeguard of the new version are wrong while the pin still points at the old one. - With a paginated or capped API (`gh api --paginate`, a files list), check that aggregates run over all pages (`jq -s`, not per page) and that a partial result fails the step instead of passing as complete. +- In bash under `set -euo pipefail`, check that each failure the script means to handle can be reached: an expected no-match `grep` in a command substitution needs a guard inside the pipeline, and `$(cmd || true)` inside `if !` or a fixture built in `$( ) ||` runs with errexit off, so the failure goes unnoticed. +- When a doc or the pull request description states a rule, a list of conditions (status codes, methods, limits) or what a command covers, compare each item with the code or CI it names, in every place that has its own copy of the logic. Exceptions added in the same change belong in the doc and the description too, not only in a code comment.