Repository navigation
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>
…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>
…bility issues
"Show me the accessibility issues from Automate build <link>" had no route:
the Accessibility API takes only its own build id and answers an Automate
build id with 404, and nothing mapped one to the other.
A session run through the BrowserStack SDK belongs to the SDK's build, whose
id is also the Accessibility build id, and the session's test-code record
(GET /ext/v1/sessions/{id}/testCode, already used for self-healing) names it
as build_uuid. So reportUrl now takes an Automate session link (one call) or
build link (one more call, for any of its sessions) and reads that build's
issues through the existing build export.
A session not run through the SDK, an SDK run without accessibility testing
(a build the Accessibility API does not know) and an unknown Automate build
each get their own message instead of a bare 404, and the Automated Tests
404 hint now points at passing the Automate link.
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:
Comment |
This was referenced Oct 21, 2026
Collaborator
Author
|
Superseded by #502, the same change raised from a branch in this repo instead of a fork, so the stacked PRs show only their own changes. |
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.
"Show me the accessibility issues from Automate build <link>" had no route. The Accessibility API takes only its own build id and answers an Automate build id with 404 "Build not found", and nothing in the MCP mapped one to the other.
The mapping. A session run through the BrowserStack SDK belongs to the SDK's build, whose id is also the Accessibility build id. The session's test-code record names it as
build_uuid:GET {automation API}/ext/v1/sessions/{session_id}/testCode(public, basic auth; already used by the self-heal tools and in the TRA capability index asget_session_test_code)So
reportUrlnow also takes:…/builds/{build}/sessions/{session})build_uuid…/builds/{build})sessions.json?limit=1) →build_uuidThe resolved build then goes through #496's build export, so the count, duplicate folding, CSV link and paging are unchanged. A session link reads the whole build's issues; the tool description says so.
Failures say what happened instead of surfacing as a bare 404 from the export:
testCode404)The Automated Tests 404 hint (wrong kind of build id) now points at passing the Automate link as
reportUrl.Verification
Ran this branch's build against the real API:
reportUrlNew tests cover both link shapes and the three failure cases;
npm run build(lint, format, 1332 tests, tsc) passes.Not in this PR: reading only one session's test (rather than its whole build). The build's
testRunstree links a session to its Accessibility test case (retries[].uuid), but how retried tests map sessions to attempts is unverified.🤖 Generated with Claude Code