fix(a11y): guard each overwriteCommand in the accessibility wrap loop [SDK-7452] by kamal-kaur04 · Pull Request #212 · browserstack/wdio-browserstack-service

kamal-kaur04 · 2026-09-22T07:39:50Z

What is this about?

AccessibilityModule.onBeforeExecute wrapped every entry of the server-sent
accessibility.options.commandsToWrap list in a single unguarded loop.

The list can name a command the active driver never registered: an appium session omits
web-only commands, and the binary also sends Selenium-shaped entries at the tail of the list
(startA11yScanning, stopA11yScanning, performScan, class HttpCommandExecutor,
library org.openqa.selenium) that are meant for another SDK. @wdio/utils monad.js
throws for a name absent from the driver's command registry, so the first such entry escaped
the forEach, aborted the rest of onBeforeExecute, and surfaced as:

ERROR @wdio/browserstack-service/cli: Error in onBeforeExecute: Error: overwriteCommand: no command to be overwritten: startA11yScanning

Every entry after the first unknown name was silently left unwrapped.

Each overwriteCommand call is now guarded individually — an unknown name is skipped at
debug level and the rest of the list still wraps. The guard body is byte-identical to the one
already shipped on the v9 line in 8539e5f; this back-ports it to v8, so the two branches
converge rather than diverge.

A per-command guard is used rather than a filter on class/library, because it also covers
the appium case (a driver legitimately not registering a web-only command), which a filter on
the Selenium-shaped entries would not.

Verification

	production `8.48.0`	this branch
`Error in onBeforeExecute: overwriteCommand...`	present	absent
`TypeError: browser.stopA11yScanning is not a function`	present	absent
WDIO spec result (App Automate iOS, `run-sample-test-stop-a11y`)	`FAILED in ios`	`PASSED in ios`
Test Observability `build_status_stats`	fail	pass
O11Y build	`3tlcu82axqlqqzfkwwxm16e4h2irkgct9wwgdub9`	`6or8l79ooffi9veslxggg7qggxoqmabqh3i3mgpr`

Unit-level: reverting only accessibilityModule.ts to origin/v8 makes the new test fail with
the exact production error string and overwriteCommand called 2 of 3 times; with the guard it
is called 3 of 3. Full suite on node 18.20.4: npm run build clean, 46/46 files, 1048/1048 tests.

Related Jira task/s

https://browserstack.atlassian.net/browse/SDK-7452

Release (mandatory for every PR — required for the `ready-for-review` label)

Version bump: (required — tick exactly one)

minor (backwards-compatible feature)
patch (bug fix or other small change)

Release notes type: (optional)

New Feature
Bug Fix
Other Improvement

Release notes (customer-facing): (optional but encouraged)

Fixed accessibility command wrapping aborting on App Automate sessions, which logged Error in onBeforeExecute and left the remaining commands unwrapped for auto-scanning. Applies to both the CLI and the non-CLI flow.
Accessibility results and summary failures now report the HTTP status, the response body and the identifiers the query used, instead of an empty result with no explanation.

Release notes (internal): (required — engineer-facing; what actually changed / why)

AccessibilityModule.onBeforeExecute now guards each browser.overwriteCommand call individually, so a commandsToWrap entry the driver never registered is skipped (debug-logged) instead of throwing out of the forEach and aborting the rest of the hook. Back-port of 8539e5f from the v9 line; the guard body is byte-identical there.
AccessibilityHandler.before() (the non-CLI flow) iterates the same server-sent commandsToWrap list and was equally unguarded — and, unlike the CLI path, has no try/catch of its own, so a throw rejected the whole hook. v9 already guards this loop; that guard is ported here, with a regression test (the shared browser mock had no overwriteCommand, so no existing case reached this loop).
getAppA11yResults / getAppA11yResultsSummary / getA11yResultsSummary caught with a bare catch and logged a fixed string, discarding the cause. They now render the caught value (pollApi rejects with a plain object, so ${error} produced [object Object]) and name the testRunUuid / sessionId queried.
pollApi now carries statusCode and body on its rejection and falls back to HTTP <code>: <body> when the error body has no message key, and guards JSON.parse so a non-JSON error body no longer replaces the real failure with a SyntaxError.

Checklist

Ready to review
Has it been tested locally?

PR Validations

Run Tests: Comment RUN_TESTS to trigger sanity tests.

🤖 Generated with Claude Code

AccessibilityModule.onBeforeExecute wrapped every entry of the server-sent commandsToWrap list in one unguarded loop. The list can name a command the active driver never registered: appium sessions omit web-only commands, and the list also carries Selenium-shaped entries (startA11yScanning, stopA11yScanning, performScan with class HttpCommandExecutor, library org.openqa.selenium) meant for other SDKs. WebdriverIO's overwriteCommand throws on an unknown name, so the first such entry aborted the whole loop, left every command after it unwrapped, and surfaced as "Error in onBeforeExecute: overwriteCommand: no command to be overwritten: startA11yScanning". Guard each overwriteCommand call individually so an unknown name is skipped (debug-logged) and the rest of the list still wraps. Ports the guard already shipped on the v9 line in 8539e5f to v8. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…9 line The v8 guard body is byte-identical to the one on v9; the comment was not. Drop the v8-specific narrative for v9's rationale, minus the isAppAccessibility history that never applied to v8. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

changeset-from-pr.yml generates .changeset/pr-<number>.md from the PR's Release section on this branch, so a hand-written file only duplicates the CHANGELOG entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

coderabbitai · 2026-09-22T07:39:57Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited), Workspace UI (inherited)

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 5f3f9399-fba6-42a3-89a1-1d1125d14456

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

_{Comment @coderabbitai help to get the list of available commands.}

kamal-kaur04 · 2026-09-22T09:35:16Z

🔴 Blocking findings — fix required

Severity	File · Symbol	Finding
🟠 Warning	`packages/browserstack-service/src/util.ts · pollApi`	New pollApi error-shape behaviour lands without a test driving the real catch
🟠 Warning	`packages/browserstack-service/tests/accessibility-handler.test.ts · describe('before') > it('skips a command the driver did not register without aborting the wrap loop')`	New test permanently stubs `utils.validateCapsWithA11y` to `true` with no restore

Full reasoning, evidence and suggested fixes are in the SDK PR Review Agent's report from your local run.

Change map (generated deterministically from the diff)

graph LR
  subgraph nnode_agent["node-agent"]
    npackages_browserstack_service_src_cli_modules_accessibilityModule_ts["accessibilityModule.ts<br/>~27 lines"]
    npackages_browserstack_service_tests_cli_modules_accessibilityModule_test_ts["accessibilityModule.test.ts<br/>~27 lines"]
    npackages_browserstack_service_src_util_ts["util.ts<br/>~23 lines"]
    npackages_browserstack_service_src_accessibility_handler_ts["accessibility-handler.ts<br/>~19 lines"]
    npackages_browserstack_service_tests_accessibility_handler_test_ts["accessibility-handler.test.ts<br/>~19 lines"]
    n_changeset_pr_212_md["pr-212.md<br/>~6 lines"]
  end

↻ This verdict comment is the review anchor — it's updated in place on each run (the gate posts its status separately).

— SDK PR Review Agent

kamal-kaur04 · 2026-09-22T09:51:38Z

Review findings (relay)

The automated review comment above posted as ⚠️ pending with an empty body — a harness bug (a crash while rendering the "Process integrity" section) swallowed the report, and a second gate issue held the marker amber. Neither reflects the PR. Relaying the two findings here so they aren't lost; both were confirmed after the falsification pass.

1. Critical — the per-command guard lands only on the CLI flow

packages/browserstack-service/src/cli/modules/accessibilityModule.ts · AccessibilityModule.onBeforeExecute

The same wrap loop exists a second time in the non-CLI (service/direct) flow. src/accessibility-handler.ts:242-250 reads the same accessibilityScripts.commandsToWrap global, passes the same command.class === 'Element' argument, and calls browser.overwriteCommand(...) with no per-command boundary.

If that flow receives the same server-sent list, the first Selenium-shaped entry (startA11yScanning / stopA11yScanning / performScan, class HttpCommandExecutor) throws and every command after it goes unwrapped — the exact SDK-7452 symptom, just on the other flow. This PR doesn't touch that file.

What could be established: the counterpart call site exists, is unguarded on that line, and iterates the identical source list. What could not be established: whether accessibility-handler.ts is reachable for the App Automate configuration in the ticket, and whether an enclosing guard there already isolates per-command failures.

Suggested fix — either mirror the guard at accessibility-handler.ts:250 (same try/catch + logger.debug skip), or state in the PR description / changeset why the service flow cannot receive the Selenium-shaped entries and is out of scope. A shared safeOverwriteCommand(browser, command) used by both call sites would stop the two drifting again.

2. Critical — the new test mutates the shared accessibilityScripts singleton and restores it only on the success path

packages/browserstack-service/tests/cli/modules/accessibilityModule.test.ts · skips a command the driver did not register without aborting the wrap loop

The test assigns three entries to the module-scope singleton accessibilityScripts.commandsToWrap and restores it as the last statement of the test body. That restore is skipped whenever anything above it throws — an expect failure, or onBeforeExecute rejecting — and the file's afterEach only calls vi.resetAllMocks(), which resets mock functions but does not restore a plain property written onto the mocked module's default export.

A failing run therefore leaks a populated commandsToWrap into every later test in the file, turning one real failure into a cascade of unrelated ones. It also restores a hardcoded [] rather than the captured original, which becomes silently wrong if the shared mock ever gains a non-empty default.

Suggested fix:

const originalCommandsToWrap = accessibilityScripts.commandsToWrap
try {
    accessibilityScripts.commandsToWrap = [...] as any
    // ...arrange, act, assert
} finally {
    accessibilityScripts.commandsToWrap = originalCommandsToWrap
}

or move the save/restore into beforeEach/afterEach for the describe block so any future test touching the singleton inherits the cleanup.

What's good: the regression test is a real one — asserting overwriteCommand was called 3 times and last called with addValue proves the loop continued past the throwing entry. The catch logs the skipped command name at debug level so the degradation stays visible, and the guard is scoped to the single overwriteCommand call rather than the whole loop, so it can't mask an unrelated failure in onBeforeExecute.

Coverage: 4 of 4 diff regions judged, no gaps. .changeset/pr-212.md clean.

getAppA11yResultsSummary and getA11yResultsSummary caught their failure with a bare `catch`, logged a fixed "No accessibility summary was found." and returned {}. The sibling getters (getAppA11yResults, getA11yResults) bind the error and debug-log it; these two discarded it. The message is the same whether the results API errored, returned nothing, or the 30s poll in getAppA11yResultResponse timed out, so an empty summary on a real run cannot be told apart from an API failure. Bind the error and debug-log it, matching the results getters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The previous commit put the cause behind BStackLogger.debug, which does not print at the default log level -- on O11Y build t4x7uep76ef2im4wwjv0rcm6jk6aohbkrdqhni6h the run carried the change and still emitted a bare "No accessibility summary was found." with no DEBUG line anywhere. The message is already an error, so the cause belongs on that line. An empty summary now reports whether the results API errored, returned no payload, or the 30s poll in getAppA11yResultResponse timed out, without needing logLevel: debug. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

pollApi throws a plain object, not an Error: throw { data: {}, headers: {}, message: ... } so `${error}` produced a literal "[object Object]" — which is what O11Y build eo2oxrhccxnhwxf5f3gcg4i8zqhx2ddsgagusp93 logged, still saying nothing about the cause. The useful field is `message`, carrying the server's message from the response body. Render `error?.message` with a util.inspect fallback, in all three getters. The results getter also stops claiming "No accessibility summary was found" when it failed to fetch results, and drops its debug duplicate. Worth noting for whoever reads the next failure: of pollApi's paths only a non-404 error response throws. A poll that exhausts the upper time limit, a 404 with a missing next_poll_time header, and a request with no response all RETURN { data: {} } instead. So this error line means a hard HTTP error from the results API, not a timeout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A local App Automate run of the android start-a11y cell produced: ERROR @wdio/browserstack-service: No accessibility summary was found. Error: { data: {}, headers: {}, message: undefined } message is undefined because the results API answered with a JSON body that has no `message` field — the ternary only covers an EMPTY body, so a JSON error body of any other shape yields undefined and the reader learns nothing. The status code and the body itself were never carried at all. Carry statusCode and body on the rejection, and fall back to `HTTP <code>: <body>` when the body has no message, so an empty summary always names the HTTP failure behind it. JSON.parse is also guarded: a non-JSON error body previously threw inside the catch, replacing the real failure with a SyntaxError. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A local run showed the results API answering HTTP 422 "test_run_uuid is invalid", but the log did not say which uuid was sent, so the failure could not be attributed to the SDK or to the service. Both App A11y getters now report testRunUuid and sessionId alongside the error. Neither is a secret; the a11y JWT is still never logged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

AccessibilityHandler.before() iterates the SAME server-sent accessibilityScripts.commandsToWrap list as the CLI module and called browser.overwriteCommand with no per-command boundary, so the Selenium-shaped entries (startA11yScanning/stopA11yScanning/performScan, class HttpCommandExecutor) produce the SDK-7452 symptom on that flow as well. It is reachable for App Automate — the handler takes isAppAutomate and branches on isAppAccessibilityAutomationSession — and before() has no try/catch of its own, so a throw rejects the whole hook rather than being logged as it is on the CLI side. v9 already guards this loop; this ports that guard, including its debug message. v9's prevImpl/orig binding is a separate change needing a different commandWrapper signature and is deliberately not ported. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The regression test assigned to the module-scope accessibilityScripts singleton and reset it as the last statement of the test body, so any earlier throw — a failed expect, or onBeforeExecute rejecting — left a populated commandsToWrap behind for every later test in the file, turning one real failure into a cascade. afterEach only calls vi.resetAllMocks(), which does not restore a plain property written onto the mocked module. Capture the original and restore it in a finally block, rather than resetting to a hardcoded [] that would be wrong if the shared mock ever gains a non-empty default. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kamal-kaur04 · 2026-09-23T07:12:53Z

Review findings addressed

Both findings were valid. Fixed in ec9b48d and 7985b7b.

1. The per-command guard lands only on the CLI flow — confirmed, and the two questions the review left open both resolve against the code:

Is accessibility-handler.ts reachable for App Automate? Yes. The handler takes isAppAutomate and branches on isAppAccessibilityAutomationSession(this._accessibility, this.isAppAutomate) for results, summary and scan.
Does an enclosing guard isolate per-command failures there? No. The loop sits in before(sessionId), which has no try/catch of its own — so a throw rejects the whole hook, rather than being swallowed and logged as it is on the CLI side. That flow is the worse of the two, not the safer one.

The deciding detail: v9 already guards this loop (main, inside the same forEach). v8 was simply behind, so ec9b48d ports that guard — same placement, same Exception in overwrite command ${command.name} - ${error} debug message.

Deliberately not ported from v9: its prevImpl / orig binding. That is a separate change requiring a different commandWrapper signature, and pulling it in here would mix an unrelated behaviour change into a guard fix.

On the suggested shared safeOverwriteCommand(browser, command) helper — agreed it is the better long-term shape, but introducing it on v8 alone would create exactly the v8↔v9 drift it is meant to prevent, since v9 has two guarded-but-differently-shaped call sites. It belongs on main first and then back-ported. Not done here.

2. The new test mutates the shared accessibilityScripts singleton and restores only on the success path — confirmed exactly as described. afterEach runs vi.resetAllMocks(), which resets mock functions but does not restore a plain property written onto the mocked module's default export, so a failing run leaked a populated commandsToWrap into every later test in the file.

7985b7b captures the original and restores it in a finally, rather than resetting to a hardcoded [] that would become wrong if the shared mock ever gains a non-empty default.

Full suite after both: build clean, 46/46 files, 1048/1048 tests, accessibilityModule.test.ts 28/28.

🤖 Generated with Claude Code

github-actions · 2026-09-23T08:06:44Z

🔴 SDK PR Review gate is red. Pending:

The SDK PR Review Agent has not reviewed the current head commit yet — run the SDK PR Review Agent.

It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge.

kamal-kaur04 · 2026-09-23T08:28:58Z

RUN_TESTS

github-actions · 2026-09-23T08:36:42Z

🟢 SDK PR Review gate is green — the SDK PR Review Agent has run on the current head commit (verdict: failure).

This gate confirms a review ran on the latest commit. The verdict itself is advisory — read the findings and use your judgement; it does not block merge. A native GitHub reviewer approval is still separately required by branch protection before this PR can merge.

github-actions · 2026-09-23T09:01:48Z

🟢 SDK PR Review gate is green — the SDK PR Review Agent has run on the current head commit (verdict: failure).

This gate confirms a review ran on the latest commit. The verdict itself is advisory — read the findings and use your judgement; it does not block merge. A native GitHub reviewer approval is still separately required by branch protection before this PR can merge.

github-actions · 2026-09-23T09:36:48Z

🔴 SDK PR Review gate is red. Pending:

The SDK PR Review Agent reported blocking findings (🔴) on the current head commit — fix them and re-run the agent.

It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge.

kamal-kaur04 · 2026-09-23T09:42:02Z

                const browser = this._browser as WebdriverIO.Browser
-                browser.overwriteCommand(command.name, this.commandWrapper.bind(this, command), command.class === 'Element')
+                try {
+                    browser.overwriteCommand(command.name, this.commandWrapper.bind(this, command), command.class === 'Element')


Warning — the service-flow guard ships without the regression test its CLI-flow twin got.

The guard itself is correct, to be clear: browser.overwriteCommand is synchronous and throws when the driver has no matching base command, so this try/catch confines a single bad accessibilityScripts.commandsToWrap entry to its own iteration, the forEach continues wrapping the rest, PerformanceTester.end(...) below is now reached, and the failure still surfaces via BStackLogger.debug with both the command name and the error.

What's missing is the evidence. This is the mirror of the change to src/cli/modules/accessibilityModule.ts in the same PR, and that side did get a regression test — "skips a command the driver did not register without aborting the wrap loop". The service flow has its own established suite at packages/browserstack-service/tests/accessibility-handler.test.ts, which this PR doesn't touch.

That asymmetry matters because of how this failure presents: the loop aborting on the first Selenium-shaped entry exits 0 and shows up only as silently unwrapped commands and zero accessibility scans. So the untested half is precisely the one that can regress unnoticed while the CLI half stays green in CI.

Suggested fix — add the symmetric case to tests/accessibility-handler.test.ts: stub accessibilityScripts.commandsToWrap with three entries, mock browser.overwriteCommand to throw on the first call, invoke the before path, then assert that (a) overwriteCommand was still called for the remaining two entries and (b) the method returns normally.

Capture and restore the original commandsToWrap in beforeEach/afterEach rather than inside the test body — the CLI test learned that one the hard way, so a failing assertion here can't leak the mutated singleton into later tests in the file.

DEF-12: the guard added to AccessibilityHandler.before() changed behaviour in a file the repo tests densely (accessibility-handler.test.ts, 26 cases) with no test of its own. Drives the real payload shape — an HttpCommandExecutor-class startA11yScanning between two Element commands — and asserts all three wraps are attempted and the trailing command still wraps. Verified to fail without the guard ("expected spy to be called 3 times, but got 2") and pass with it. The existing suite never reached this loop: the shared browser mock has no overwriteCommand, so `'overwriteCommand' in browser` was false in every other case. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

github-actions · 2026-09-23T09:50:26Z

🔴 SDK PR Review gate is red. Pending:

The SDK PR Review Agent has not reviewed the current head commit yet — run the SDK PR Review Agent.

It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge.

github-actions · 2026-09-23T10:42:10Z

🟢 SDK PR Review gate is green — the SDK PR Review Agent has run on the current head commit (verdict: failure).

This gate confirms a review ran on the latest commit. The verdict itself is advisory — read the findings and use your judgement; it does not block merge. A native GitHub reviewer approval is still separately required by branch protection before this PR can merge.

github-actions · 2026-09-23T10:47:22Z

🔴 SDK PR Review gate is red. Pending:

The SDK PR Review Agent reported blocking findings (🔴) on the current head commit — fix them and re-run the agent.

It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge.

kamal-kaur04 · 2026-09-23T10:48:40Z

RUN_TESTS

github-actions · 2026-09-23T11:06:06Z

🔴 SDK PR Review gate is red. Pending:

The SDK PR Review Agent reported blocking findings (🔴) on the current head commit — fix them and re-run the agent.

It turns green once the latest SDK PR Review Agent run reports GTG on the current head commit. A native reviewer approval is separately required by branch protection before merge.

…and-wrap

github-actions · 2026-09-23T12:06:56Z

🟢 SDK PR Review gate is green — the SDK PR Review Agent has run on the current head commit (verdict: failure).

This gate confirms a review ran on the latest commit. The verdict itself is advisory — read the findings and use your judgement; it does not block merge. A native GitHub reviewer approval is still separately required by branch protection before this PR can merge.

github-actions · 2026-09-23T13:21:42Z

🟢 SDK PR Review gate is green — the SDK PR Review Agent has run on the current head commit (verdict: failure).

This gate confirms a review ran on the latest commit. The verdict itself is advisory — read the findings and use your judgement; it does not block merge. A native GitHub reviewer approval is still separately required by branch protection before this PR can merge.

kamal-kaur04 · 2026-09-23T13:22:01Z

RUN_TESTS

kamal-kaur04 · 2026-09-23T13:33:50Z

Recurring 2 failures : https://automation.browserstack.com/projects/WDIO+v8+SDK-QA+Project/builds/WDIO+SDK-QA+Automation/267

kamal-kaur04 and others added 3 commits September 21, 2026 18:52

chore: drop the hand-written changeset

5e8c8ff

changeset-from-pr.yml generates .changeset/pr-<number>.md from the PR's Release section on this branch, so a hand-written file only duplicates the CHANGELOG entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

kamal-kaur04 requested a review from a team as a code owner September 22, 2026 07:39

kamal-kaur04 requested review from AakashHotchandani and pranay-v29 and removed request for a team September 22, 2026 07:39

chore(changeset): auto-generate from PR template (patch)

2443f4d

kamal-kaur04 and others added 7 commits September 22, 2026 20:25

kamal-kaur04 added the ready-for-review label Sep 23, 2026

kamal-kaur04 added ready-for-review and removed ready-for-review labels Sep 23, 2026

kamal-kaur04 commented Sep 23, 2026

View reviewed changes

kamal-kaur04 and others added 2 commits September 23, 2026 15:17

chore(changeset): auto-generate from PR template (patch)

969aa7d

kamal-kaur04 added ready-for-review and removed ready-for-review labels Sep 23, 2026

kamal-kaur04 commented Sep 23, 2026

View reviewed changes

Comment thread .changeset/pr-212.md

kamal-kaur04 commented Sep 23, 2026

View reviewed changes

Comment thread packages/browserstack-service/src/util.ts

rounak610 mentioned this pull request Sep 23, 2026

ci(sdk-pr-review-gate): green when the agent RAN on the latest commit, not only when it passes (v8) #217

Merged

7 tasks

Merge remote-tracking branch 'origin/v8' into fix/SDK-7452-guard-comm…

7c37126

…and-wrap

harshit-browserstack approved these changes Sep 23, 2026

View reviewed changes

pranay-v29 approved these changes Sep 23, 2026

View reviewed changes

kamal-kaur04 added ready-for-review and removed ready-for-review labels Sep 23, 2026

kamal-kaur04 mentioned this pull request Sep 24, 2026

Release v8 24 sep #225

Merged

7 tasks

hamza-browserstack merged commit 1d8ce38 into v8 Sep 24, 2026
14 of 19 checks passed

Conversation

kamal-kaur04 commented Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What is this about?

Related Jira task/s

Release (mandatory for every PR — required for the ready-for-review label)

Checklist

PR Validations

Uh oh!

coderabbitai Bot commented Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

kamal-kaur04 commented Sep 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Change map (generated deterministically from the diff)

Uh oh!

kamal-kaur04 commented Sep 22, 2026

Review findings (relay)

Uh oh!

kamal-kaur04 commented Sep 23, 2026

Review findings addressed

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

kamal-kaur04 commented Sep 23, 2026

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

kamal-kaur04 Sep 23, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

kamal-kaur04 commented Sep 23, 2026

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

github-actions Bot commented Sep 23, 2026

Uh oh!

kamal-kaur04 commented Sep 23, 2026

Uh oh!

kamal-kaur04 commented Sep 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kamal-kaur04 commented Sep 22, 2026 •

edited

Loading

Release (mandatory for every PR — required for the `ready-for-review` label)

coderabbitai Bot commented Sep 22, 2026 •

edited

Loading

kamal-kaur04 commented Sep 22, 2026 •

edited

Loading