[oss-candidate] rework r1: jbetancur/react-data-table-component#1394

[askalf]

Maintainer said

jbetancur, 2026-09-22T11:16:48Z, on CHANGELOG.md line 21 (jbetancur#1394 (comment)):

Sorry I should have been more clear. This needs to land in a new entry for 8.10.1 since 8.10.0 was already released

Context: v8.10.0 was tagged on 2026-09-06 (a3473b0 chore: release v8.10.0 [skip ci]). At the submitted head 92f7524 the bullet for this fix sat under ## 8.10.0 / ### Bug fixes, i.e. inside a section that has already shipped.

Change

CHANGELOG.md:5-12 (one commit, 63253d8, docs: file the pinned scrollbar fix under a new 8.10.1 changelog entry): a new ## 8.10.1 section with its own ### Bug fixes heading and --- separator is inserted above ## 8.10.0, in the file's existing format; the bullet moves there unchanged, and the ## 8.10.0 section is restored byte-for-byte to upstream master. No other file changes in this round.

Diff of CHANGELOG.md against upstream master (424d21c) at this head:

@@ -2,6 +2,14 @@

 A summary of notable changes per release. For the full commit history see the [repository on GitHub](https://github.com/jbetancur/react-data-table-component/commits/master).

+## 8.10.1
+
+### Bug fixes
+
+- **Pinned scrollbar** now sets `aria-controls` to the scroll container's real id. When the container already carried an id, or was labelled again after an unpin and re-pin, the thumb kept pointing at a generated id no element had, so assistive technology could not resolve what the scrollbar controlled.
+
+---
+
 ## 8.10.0

 ### New features

Evidence, using the exact awk the release workflow runs to extract release notes (.github/workflows/release.yml:101):

== submitted head 92f7524: extract 8.10.1 ==
(rc=0 ; lines: 0)
== submitted head: grep Pinned scrollbar in 8.10.0 section ==
1
== worktree after change: extract 8.10.1 ==

### Bug fixes

- **Pinned scrollbar** now sets `aria-controls` to the scroll container's real id. When the container already carried an id, or was labelled again after an unpin and re-pin, the thumb kept pointing at a generated id no element had, so assistive technology could not resolve what the scrollbar controlled.

== worktree after change: Pinned scrollbar in 8.10.0 section ==
0
== 8.10.0 section identical to upstream master ==
IDENTICAL

So before the change, a future 8.10.1 release would have extracted empty notes and the bullet would have been misfiled under a shipped version; after it, the 8.10.1 extraction yields exactly this bullet and the 8.10.0 section is the released one.

Branch diff against upstream master at this head: CHANGELOG.md +8, CLAUDE.md (pre-existing, merge-base drift: upstream jbetancur#1395 changed the same line after our branch point), src/__tests__/pinning.test.tsx +193, src/components/PinnedScrollbar.tsx +6/-1. Only CHANGELOG.md differs from the submitted head 92f7524.

CI chain (npm run lint && npm run typecheck && npm test && npm run build, as .github/workflows/ci.yml runs it): see ## CI below.

CI

Local run of the exact chain .github/workflows/ci.yml executes (npm ci, npm run lint, npm run typecheck, npm test scoped to the touched test file, npm run build) at 63253d8, Node v24.19.0 (log: /agent-output/oss/react-data-table-component/r1-ci-chain.log):

added 460 packages in 10s
LINT_OK
TSC_OK
 ✓ src/__tests__/pinning.test.tsx (24 tests) 627ms
 Test Files  1 passed (1)
      Tests  24 passed (24)
   Duration  3.13s (environment 42%, transform 25%, tests 21%, import 6%, setup 5%)
TEST_OK
BUILD_OK

Nothing in eslint.config.js, tsconfig.json, tsup.config.ts or vitest.config.ts reads CHANGELOG.md, so the only tool that consumes it is the release workflow's awk extraction shown above. Fork CI: gh pr checks 2 reports no checks (the fork's ci.yml triggers on pull_request to master only, and this staging PR targets the feature branch; upstream CI at 92f7524 was already green after the previous round). Upstream CI at the new head will run once the Scout fast-forwards the submitted branch; the maintainer must approve the fork workflow as before.

Reply

Moved the entry into a new ## 8.10.1 section above ## 8.10.0 in 63253d8, with its own ### Bug fixes heading in the file's format. The ## 8.10.0 section is now identical to master again, and the release workflow's notes extraction for 8.10.1 returns just this bullet.

[askalf]

Verification at 63253d8

Attacked this rework round as an independent execution (not resuming a prior verify) against baseRefOid 92f7524 (the submitted branch).

Superseded check

gh api "repos/jbetancur/react-data-table-component/commits?path=CHANGELOG.md&since=2026-09-20T00:00:00Z" — empty. No commit has touched CHANGELOG.md on upstream master since the 8.10.0 release (e6bc5686, 2026-09-06), so the maintainer's ask has not been independently fixed. Upstream PR jbetancur#1394 is still OPEN, mergedAt: null. Proceeding.

Diff shape

git diff 92f7524..63253d8 --stat = CHANGELOG.md | 9 ++++++++- only, one commit. No other file changed in this round.

The change, executed

git diff origin/master -- CHANGELOG.md at 63253d8 (upstream master = 424d21c):

@@ -2,6 +2,14 @@
 A summary of notable changes per release. ...

+## 8.10.1
+
+### Bug fixes
+
+- **Pinned scrollbar** now sets `aria-controls` to the scroll container's real id. ...
+
+---
+
 ## 8.10.0

 ### New features

Only the new 8.10.1 block is added; nothing else in the file differs from upstream master.

## Reply checked against the diff

The reply says: "Moved the entry into a new ## 8.10.1 section above ## 8.10.0 in 63253d8, with its own ### Bug fixes heading in the file's format. The ## 8.10.0 section is now identical to master again, and the release workflow's notes extraction for 8.10.1 returns just this bullet." All three claims independently executed below; the reply states nothing the diff does not do.

Release-notes extraction (.github/workflows/release.yml:101), run verbatim

$ VERSION="8.10.1"; awk "/^## ${VERSION}\$/{found=1; next} found && /^(---|## )/{exit} found{print}" CHANGELOG.md
(blank line)
### Bug fixes
(blank line)
- **Pinned scrollbar** now sets `aria-controls` to the scroll container's real id. When the container already carried an id, or was labelled again after an unpin and re-pin, the thumb kept pointing at a generated id no element had, so assistive technology could not resolve what the scrollbar controlled.
rc=0 lines=5

Same extraction at the submitted head 92f7524 (before this round): lines=0 — a release cut from that head would have shipped empty notes for 8.10.1 and the bullet would have stayed misfiled under the already-shipped 8.10.0.

## 8.10.0 section restored, checked byte-for-byte

$ awk "/^## 8.10.0\$/{found=1} found{print} found && /^---\$/ && NR>1{if(c++>0)exit}" CHANGELOG.md > /tmp/810_head.txt
$ git show origin/master:CHANGELOG.md | awk "/^## 8.10.0\$/{found=1} found{print} found && /^---\$/ && NR>1{if(c++>0)exit}" > /tmp/810_master.txt
$ diff /tmp/810_head.txt /tmp/810_master.txt && echo IDENTICAL
IDENTICAL

Em dash check

grep -c $'\xe2\x80\x94' CHANGELOG.md = 36, all pre-existing arrow-link characters (→) elsewhere in the file (UTF-8 byte sequence collision with the em-dash grep, checked by eye — none in the added 8.10.1 block). git diff origin/master -- CHANGELOG.md | grep -E $'\xe2\x80\x94' on just the added lines returns nothing.

CI chain, run in full (not just the tool that would go red)

Local run of the exact chain .github/workflows/ci.yml executes, Node v24.19.0, at 63253d8:

== LINT ==
LINT_OK
== TYPECHECK ==
TSC_OK
== TEST ==
 ✓ src/__tests__/pinning.test.tsx (24 tests) 684ms
 Test Files  1 passed (1)
      Tests  24 passed (24)
TEST_OK
== BUILD ==
...
DTS ⚡️ Build success in 5562ms
DTS dist/index.d.mts 28.20 KB
DTS dist/index.d.ts  28.20 KB
BUILD_OK

Full log: /agent-output/oss/react-data-table-component/r1-verify-ci-chain-clean.log.

Fork checks

gh pr checks 2 --repo sprayberry-code/react-data-table-component → "no checks reported on the 'fix/pinned-scrollbar-aria-controls-r1' branch" — absence, not failure: the fork's ci.yml triggers only on pull_request to master, and this staging PR targets the feature branch, matching the ticket's note.

Verdict

Change and reply both hold at 63253d8. Nothing to push to this branch (test-only additions are not applicable here; the change is doc-only and the existing 24/24 pinning suite plus the full CI chain already cover the src the round did not touch).

Rules: none matched.

[sprayberry-redline]

Automated review from the Sprayberry Labs fleet code reviewer.
Reviewed by the gating lane (gating review).

Verdict: APPROVE — the rework correctly files the existing fix under a new 8.10.1 entry and the reply accurately describes the diff and release-note extraction.

What's good: CHANGELOG.md:5-12 adds a standalone ## 8.10.1, its own ### Bug fixes, and the file's --- delimiter, while the moved bullet is removed from the already-released 8.10.0 section. I independently ran the release workflow's extraction pattern against the live head: it returns the new Bug fixes section and exactly the pinned-scrollbar bullet. I also compared the live and upstream-master 8.10.0 sections; their SHA-256 digests match exactly. The required verification marker names the live head. There are no fork checks reported for this staging branch, so I did not treat unavailable fork CI as a passing CI signal; this changelog-only change was reviewed on its diff and the documented extraction evidence.

The single commit has no body attribution, and I found no generated-writing or reply-specific blocking issue in the changed text or ## Reply.

Reviewed scope: the one-file changelog diff, the upstream release workflow extraction at .github/workflows/release.yml:96-106, the PR reply, live verification marker, and the release-section comparison. I did not rerun the repository test suite, per review environment policy.

[askalf]

Pushed upstream.