{{ message }}
Repository navigation
fix(accessibility): match the dashboard's issue count and keep the report link intact - #500
Merged
Merged
Conversation
The issues export has a row for every occurrence. In a grouped report each repeated occurrence carries a "Duplicate Issue of" link to its main issue, and the dashboard leaves those rows out of its issue count. startAccessibilityScan and fetchAccessibilityIssues counted every row, so a scan the dashboard shows as 79 issues was reported as "We found 122 issues". The parser now returns main issues only, folds each duplicate into the issue its link points at (duplicate_count), and returns how many duplicates it left out; both tools state that number next to the total. A duplicate whose main issue cannot be identified is counted only there. Reports without the "Duplicate Issue of" column are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The scan and issue tools return one text block per message. A client that joins the blocks with no separator (Claude Code does) runs the report link into the next block's first word: "...&Key-Pair-Id=KWDR32L2KWU1BWe found 122 issues". The key pair id is opaque, so an agent copying the link takes the "W" with it and the download fails with 403 InvalidKey. Each block now ends with a newline. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…t was left out The dashboard counts neither duplicate occurrences nor issues hidden in it, but the export lists both, and every export carries an "Issue status" column. Hidden issues were counted: a Workflow Analyzer report the dashboard shows as 771 issues exports 1,231 rows, 123 of them hidden. A hidden issue is now left out with every occurrence of it, and the total is the dashboard's: on the dashboard's export of that report, 771 issues, 337 duplicate occurrences folded and 122 hidden issues left out. The answer says how many hidden issues it left out. The duplicates note no longer says every duplicate was folded: duplicates that could not be matched to a main issue are named as such, and duplicate_count is pointed at only when some were matched. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…low Analyzer reports fetchAccessibilityIssues read only Website Scanner runs, so an agent that ran an SDK test with accessibility on, or was handed a Workflow Analyzer report, had no way to read its issues. The API already exports both the same way as a scan run: start a CSV export, poll the same route with the task id, download the link. Only the route and its parameter names differ. The tool now takes exactly one source: scanId with scanRunId, buildId (the Accessibility build id, thBuildId in the report link), or workflowReportId. The fetcher builds each source's export URLs; the parser, duplicate folding and paging are unchanged. A build the API does not find (the Automate build id is one) gets a message naming the id to pass instead, and the next-page hint repeats the source's own arguments. Rows now carry affected_page, since builds and Workflow Analyzer reports span several pages, and source_test when the export has a "Source test" column (Automated Tests builds). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…V link An agent handed a dashboard report link had to find the ids itself, and fetchAccessibilityIssues returned parsed issues but not the CSV. Both now go through the tool. reportUrl takes a Website Scanner or Automated Tests report link. An Automated Tests link carries its build id. A Website Scanner link carries one run's thBuildId, which only the scan list can map to ids: each scan there carries its latest run's link, so the newest scans are walked (15 pages) for a match. A link to an older run is reported as such, with the scan's id, rather than guessed at. The list is walked at its default page size: at limit=50 or 100 its cursor skips scans. Every answer now includes the CSV's download link, as startAccessibilityScan already does. When a link was resolved the answer says to what, and the next-page hint uses the ids, so later pages skip the lookup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📜 Recent review details
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
This was referenced Oct 21, 2026
… budget Every client loads tool descriptions at connect time, so the prompt is back under 200 characters including the handoff sentence, and each argument's description under 120: what each id is lives in its own describe(), and where ids come from in the answers and errors. buildId is a regex (40 lowercase letters and digits) rather than prose. A test now holds every accessibility tool to the budget. Also: a dashboard link whose scan has no completed run is refused, instead of asking the API for scan_run_id=undefined. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ading its issues
An agent that fetched an SDK build's issues right after the test run got 14
issues, called final ("All issues retrieved"); the build completed minutes
later with 27. After the tests end a build stays "finalizing" (advanced
issue processing, for an advanced scan) and the export serves whatever
exists so far.
fetchAccessibilityIssues now reads the report's status first: a scan run's
status endpoint, a Workflow Analyzer report's summary, and for a build its
project's build list, since the build overview carries no status. While it
is queued, running, processing or finalizing, a first read waits, polling
every 10 s for up to 5 min with progress notifications, then reads the
issues and says it waited. If processing outlasts the wait, the answer
says the issues are only those found so far and to fetch again, instead of
"All issues retrieved". A later page does not wait again, and a status
that cannot be read is not waited on.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… its tests run
A build whose suite is still running can take as long as the suite; blocking the first
read for five minutes and then returning partial results anyway serves nobody. The wait
now covers only the post-run advanced-issue processing ("finalizing"), which ends
within minutes. A run in progress is read as it is, with the note that the issues are
those found so far.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…build-and-workflow-issues Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…1y-wait-for-processing Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SavioBS629
previously approved these changes
Oct 22, 2026
feat(accessibility): wait for a report to finish processing before reading its issues
…orkflow-issues feat(accessibility): fetch issues of builds, Workflow Analyzer reports and dashboard links, with the CSV link
gaurav-singh-9227
approved these changes
Oct 22, 2026
This was referenced Oct 23, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three fixes to what
startAccessibilityScanandfetchAccessibilityIssuestell the agent.1. The count matches the dashboard: no duplicates
Both tools counted every row of the issues export. In a grouped report each repeated occurrence is its own row with a "Duplicate Issue of" link to its main issue, and the dashboard leaves those out of its count. So a scan the dashboard shows as 79 issues ("Excluded 43 duplicated issues") came back from the tool as "We found 122 issues".
The parser now returns main issues only and folds each duplicate into the issue its link points at (
duplicate_counton that issue). A duplicate whose link matches no main issue, or more than one, is never attributed to a specific issue. Reports without the "Duplicate Issue of" column keep every row.2. The count matches the dashboard: no hidden issues
Every export also lists issues hidden in the dashboard ("Issue status" =
hidden), which the dashboard leaves out of its count. A Workflow Analyzer report the dashboard shows as 771 issues exports 1,231 rows, 123 of them hidden. A hidden issue is now left out with every occurrence of it, including duplicates.The answer states what was left out. The duplicates note says "folded … (see duplicate_count)" only for duplicates actually matched to an issue (this addresses the CodeRabbit comment on the earlier wording):
3. The report link no longer breaks
The tools return one text block per message, and a client that joins blocks with no separator (Claude Code does) ran the CSV link into the next sentence:
…&Key-Pair-Id=KWDR32L2KWU1BWe found 122 issues. The key pair id is opaque, so an agent copying the link takes theWalong and the download fails with403 InvalidKey; the same link without it downloads fine. Each block now ends with a newline.Verification
startAccessibilityScanNew tests cover grouped, link-less and ungrouped reports, hidden main issues with their duplicates, hidden rows in an ungrouped report, the note's wording for matched / unmatched duplicates, and the report link surviving a no-separator join.
npm run build(lint, format, 1310 tests, tsc) passes.The public API's Workflow Analyzer export does not carry "Duplicate Issue of" today (the dashboard's export does), so for those reports only hidden issues are left out until the API adds the column. That is being fixed in the
accessibilityrepo.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Tests