[Hitesh-IDK]

What is this about?

One-line follow-up to #315. The off-infra selfHeal warning it added can fire for a session that is on BrowserStack.

shouldAddServiceVersion() returns false for two independent reasons (util.ts):

if ((config.services && config.services.toString().includes('chromedriver') && testObservability !== false) || !isBrowserstackInfra(config, caps)) {
    return false
}

The warning only means to cover the second. In the first — the chromedriver service with testObservability left on, which is the default — a genuine BrowserStack session is told "selfHeal has no effect for sessions not running on BrowserStack infrastructure." Wrong root cause, pointed at the user.

This gates on isBrowserstackInfra() instead, which is the condition the message describes. It is already imported in launcher.ts and used for the same purpose a few lines above, so this is a one-line change. shouldAddServiceVersion stays for its other callers.

Found while porting #315 to v8 in #322, which carries the corrected gate — so v8 is currently more correct than main on this line.

Related Jira task/s

https://browserstack.atlassian.net/browse/PTAAA-881

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 a warning that could incorrectly tell users their BrowserStack session was not running on BrowserStack infrastructure.

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

• The selfHeal off-infra warning from PTAAA-881: remove extension-based self-healing and the ai-sdk-node dependency #315 gated on shouldAddServiceVersion(), which is also false for a chromedriver service with observability enabled. That misreported a genuine BrowserStack session as off-infra. Now gated on isBrowserstackInfra(), the condition the message actually describes.

Checklist

• Ready to review
• Has it been tested locally?

Verification: tsc --noEmit — 9 errors, unchanged from baseline, none in launcher.ts. vitest --run — 931 passing / 29 failing, identical to baseline (all pre-existing). eslint src/launcher.ts clean.

PR Validations

Run Tests: Comment RUN_TESTS to trigger sanity tests.

🤖 Generated with Claude Code

[Hitesh-IDK]

✅ SDK PR Review — approve. Correct one-line fix; no changes requested.

The fix is right

shouldAddServiceVersion() returns false for two independent reasons, and the warning only ever meant the second:

if ((config.services && config.services.toString().includes('chromedriver') && testObservability !== false) || !isBrowserstackInfra(config, caps)) {
    return false
}

Gating on isBrowserstackInfra() makes the condition match the message. Worth emphasising that the misfire was reachable on a default config, not an exotic one — testObservability is on by default, so any chromedriver-service user on genuine BrowserStack infra could be told their session was not on BrowserStack infrastructure.

Verified

Check	Result
isBrowserstackInfra imported	✅ launcher.ts:44
Cast follows existing convention	✅ identical pattern at launcher.ts:335
shouldAddServiceVersion retained for other callers	✅ lines 160, 200, 497
Type imports present	✅ Options (14), BrowserstackConfig (18)
Changeset	✅ correct package, patch matches the ticked bump
Warning still log-only / cannot break user tests	✅

The added cast (this._config as BrowserstackConfig & Options.Testrunner), which the v8 port did not need, is legitimate rather than noise: v9's this._config is typed Options.Testrunner while isBrowserstackInfra expects the intersection, and line 335 already does exactly this for the same call. Matching the file's existing convention is the right call over introducing a new one.

Cross-branch

This converges main with the gate already carried by #322 on v8, closing the divergence raised in that review. After this merges the two majors agree on this line.

Not verified on my side

The PR body reports vitest 931 passing / 29 failing, identical to baseline. I could not corroborate this — a sandbox clone was unavailable, and the repo's own CI run on main (89a3557, post-#315) concluded success, so CI does not surface those 29. That is not a contradiction (CI likely scopes its suite differently from a bare local vitest --run), but the "identical to baseline" claim is unconfirmed here. Given the change is one line in a branch with no test coverage either way, this does not affect the verdict — flagging it only so the number is not taken as independently checked.

Note on gate state

ready-for-review is not applied and the checklist item is unticked, so check-ready is red and this PR is not yet in reviewable state by the repo's own convention. This verdict satisfies the review half of the SDK PR Review Gate; the gate will stay red until the label is applied.

[github-actions]

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

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.

[coderabbitai]

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

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Central YAML (base), Organization UI (inherited), Workspace UI (inherited); Enforced overrides: Organization
• Review profile: ASSERTIVE
• Plan: Enterprise
• Run ID: 8c1d50f0-ae81-4714-aefc-6a3b8748342a

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

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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