chore: bump js-yaml from 4.2.0 to 4.3.1 in /prqlc/bindings/js by dependabot[bot] · Pull Request #6158 · PRQL/prql

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

Sourced from js-yaml's changelog.

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

Sourced from js-yaml's changelog.

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

Sourced from js-yaml's changelog.

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

Sourced from js-yaml's changelog.

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

Sourced from js-yaml's changelog.

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

Sourced from js-yaml's changelog.

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabot · 2026-08-07T06:00:32Z

Bumps js-yaml from 4.2.0 to 4.3.1.

Changelog

Sourced from js-yaml's changelog.

4.3.1 - 2026-07-31
Security
[backport] Remove quadratic complexity from !!omap duplicate key detection.
4.3.0 - 2026-06-27
Added
[backport] Added maxTotalMergeKeys (10000) loader option to limit the total number of keys processed by YAML merge (<<) across one load() / loadAll() call.
Fixed
Restore umd builds back to es5.
Removed
[backport] maxMergeSeqLength replaced with maxTotalMergeKeys for limiting YAML merge processing.

Commits

86e91b8 4.3.1 released
c3cc4b0 Backport quadratic complexity fix for !!omap
33d05b5 4.3.0 released
663bfab Drop demo publish, to not override new v5 one.
1cb8c7b Add v4-legacy tag for publish
02f27af Restore umd builds back to es5
8be84ed Fix es5 compatibility
59423c6 Replace maxMergeSeqLength option with maxTotalMergeKeys (more robust). Ba...
6842ef6 doc polish
See full diff in compare view

Bumps [js-yaml](https://github.com/nodeca/js-yaml) from 4.2.0 to 4.3.1. - [Changelog](https://github.com/nodeca/js-yaml/blob/4.3.1/CHANGELOG.md) - [Commits](nodeca/js-yaml@4.2.0...4.3.1) --- updated-dependencies: - dependency-name: js-yaml dependency-version: 4.3.1 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…anchored review SHA (#884) A force-push doesn't just move a PR's head — GitHub also re-points the prior review's `.commit_id` at the **new** head. `tend-review`'s pre-flight guard compares that field against `HEAD_SHA` to decide whether the current commit has already been reviewed, so after a rewrite it reads `LAST_REVIEW_SHA == HEAD_SHA`, exits silently, and leaves a stale APPROVE standing as the active verdict on code the bot never read. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` submitted an empty-body APPROVE at 06:09:36Z; the head at that moment was `abb3853a` — confirmed by the `tend-mention` run the review itself triggered six seconds later, which carries `headSha=abb3853a`. Dependabot then rebased at 07:40:18Z (`head_ref_force_pushed` → `cc020720`), which re-triggered [`tend-review` 31158576591](https://github.com/PRQL/prql/actions/runs/31158576591). The agent ran the full 1 m 47 s and posted nothing. The reviews endpoint now reports that 06:09:36Z review against a commit created at 07:40:16Z: ``` {"id":4880377370,"state":"APPROVED","submitted_at":"2026-08-07T06:09:36Z", "commit_id":"cc0207205f99c5481b8404c805a16a43c91fb3af","body":""} ``` The session log shows the guard firing on exactly that, and the reasoning is correct given what it was told to read: > The current HEAD has already been reviewed and approved. There are no conversation comments, no unanswered questions directed at the bot, and no unresolved bot review threads to resolve. The triggering event was `synchronize`, not `ready_for_review`, so no exception applies. Exiting silently without posting — the existing approval stands as the active verdict. ## Control An ordinary push leaves the old anchor intact, so `.commit_id` alone cannot distinguish the two cases. On [`PRQL/prql#6159`](PRQL/prql#6159), a review submitted at 06:58:45Z still reports `commit_id=779b096d` after `177c1997` landed on top — the guard works there, which is why this has stayed invisible. ## Fix Probe the timeline for a `head_ref_force_pushed` newer than the last substantive bot review. Non-zero ⇒ the reviewed commit was rewritten away, so ignore `LAST_REVIEW_SHA` and review the head in full. The incremental path has to be skipped too: after a rewrite `LAST_REVIEW_SHA` names the current head, so `LAST_REVIEW_SHA..HEAD_SHA` is empty and every trivial-skip heuristic keyed on it under-reports the change. The existing `LAST_REVIEW_SHA` extraction is refactored to keep the whole review record rather than just `.commit_id`, so `submitted_at` comes from the same substantive-filtered pick — no second query, no risk of the two fields resolving to different reviews. Verified live against three shapes: `#6158` (force-pushed after approval) → 1; `#6159` (ordinary push) → 0; `#6161` (no prior bot review) → empty anchor, 0. ## Gates - **Evidence level**: High, **structural** — no decision point. Every force-push after a bot review re-points the anchor and defeats the comparison identically. - **Occurrences**: 2 for the failure class. This one, plus [#828](#828) — the same `LAST_REVIEW_SHA == HEAD_SHA` guard skipping a real commit because the anchor had moved to something the bot never reviewed (fixed for the reply-container mechanism in [#835](#835); the force-push mechanism is untouched by that fix). - **Magnitude**: targeted fix — one probe plus one condition, no new section. Normal bar. - Wrong-outcome shape, beyond the skipped work: the review record reads "approved `cc020720`" for a commit the bot never fetched, and the sequence generalizes to approve-then-rewrite. Evidence log: https://gist.github.com/192514ea2c36586f9b7f842a482d62ab --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

…cy PR (#890) `weekly`'s dependency-PR step skips approving when `LAST_APPROVAL_SHA == HEAD_SHA`. A force-push doesn't just move the head — GitHub re-points the prior review's commit anchor at the **new** head, so after a rebase that comparison reads true for a commit the bot never read. The PR is left carrying an `APPROVED` it never earned, and the one step that would have re-checked it declines to run. Dependency PRs are the population tend rewrites on purpose: `nightly` posts `@dependabot recreate` and ticks renovate's `rebase-check` on conflicted bot PRs, both of which force-push. ## Observed [`PRQL/prql#6158`](PRQL/prql#6158) (dependabot, `js-yaml` bump). `prql-bot` approved at 06:09:36Z; dependabot rebased at 07:40:18Z. Running the current snippet against it now: ``` HEAD_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af LAST_APPROVAL_SHA=cc0207205f99c5481b8404c805a16a43c91fb3af -> "Already approved on this commit; skipping." ``` `cc020720` was created 90 minutes after that approval. ## Fix Take the newest `head_ref_force_pushed` off the timeline and drop approvals older than it, mirroring the probe [#884](#884) adds to `review`'s three anchor sites. Switching from `gh pr view --json reviews` to the REST endpoint is what makes the filter expressible: `submitted_at` isn't in the GraphQL projection, and `gh api --jq` takes no `--arg`, so the comparison pipes to `jq`. Note the field rename that comes with it — REST carries `.commit_id`, not `.commit.oid`. The equality test also gains an `-n` guard: with no surviving approval both sides can now be empty, and `[ "" = "" ]` would skip. Fixing the approve path alone would leave the stale `APPROVED` standing on the two paths that *don't* reach it — step 2's "CI is failing, comment and skip" and "major version bump, comment and skip". Both are reachable precisely because a rebase changed something, so a rebased-into-red dependency PR would get a failure comment while still reading as bot-approved. A new item 6 dismisses any approval older than the newest rewrite on those paths, using the same `reviews/$REVIEW_ID/dismissals` call #884 gives `review`. It's idempotent — a dismissed review reports `DISMISSED`, so the filter stops matching it. ## Verified live | PR | shape | before | after | |---|---|---|---| | [`#6158`](PRQL/prql#6158) | approved, then force-pushed | skip | **proceed** | | [`#6157`](PRQL/prql#6157) | approved, no rewrite | skip | skip | | [`#6156`](PRQL/prql#6156) | approved, no rewrite | skip | skip | The two controls confirm the redundant-approval suppression the guard exists for is intact; only the rewritten case flips. The dismissal filter resolves against the same three: `#6158` selects review `4880377370` (`prql-bot`, `APPROVED`, `submitted_at` 06:09:36Z, `commit_id` `cc020720` — the post-rewrite head, re-anchored), and both controls select nothing. Flagged in the [review of #884](#884 (review)) as a separate concern from that diff, which patches `review` only. --------- Co-authored-by: tend-agent <270458913+tend-agent@users.noreply.github.com>

dependabotBot added dependencies javascript Pull requests that update Javascript code labels Aug 7, 2026

prql-bot approved these changes Aug 7, 2026
View reviewed changes

dependabotBotforce-pushed the dependabot/npm_and_yarn/prqlc/bindings/js/js-yaml-4.3.1 branch from abb3853 to cc02072Compare August 7, 2026 07:40

tend-agent mentioned this pull request Aug 7, 2026
fix(review): re-review after a force-push instead of trusting the re-anchored review SHA max-sixty/tend#884
Merged

prql-bot mentioned this pull request Aug 7, 2026
review-runs-tracking: 2026-08 #6123
Open

tend-agent mentioned this pull request Aug 7, 2026
fix(weekly): don't trust a re-anchored approval on a rebased dependency PR max-sixty/tend#890
Merged

max-sixty merged commit 6a41c1e into mainAug 7, 2026
37 checks passed

max-sixty deleted the dependabot/npm_and_yarn/prqlc/bindings/js/js-yaml-4.3.1 branch August 7, 2026 23:08