fix(SDK-4165): keep buildIdentifier when BROWSERSTACK_BUILD_NAME is set

[harshit-browserstack]

What is this about?

Launcher._handleBuildIdentifier skipped buildIdentifier resolution whenever BROWSERSTACK_BUILD_NAME was set — even though a buildName was available in that case. Its own warning (Skipping buildIdentifier as buildName is not passed.) contradicted the condition it fired under.

The skip was also partial. It deleted buildIdentifier from the capabilities but left this._buildIdentifier holding the unresolved #${BUILD_NUMBER} template, and onPrepare forwards that field to TestHub as build_identifier (src/launcher.ts:445).

Net effect: successive runs sharing a build name were never disambiguated, so their sessions collapsed into a single build instead of name #1, name #2.

The guard now keys solely on the absence of a buildName — which is exactly what its warning always claimed, and what the binary's handleBuildIdentifier already does (the equivalent BROWSERSTACK_BUILD_NAME skip is commented out there, core/config/index.js:1203-1211). The skip path additionally clears _buildIdentifier so a raw template is never reported as a value.

Scope of impact. CLIUtils.CLISupportedFrameworks = ['mocha'], and the CLI is also disabled for multiremote. For every other configuration — WDIO + jasmine, WDIO + cucumber, and any multiremote run — the classic launchTestSession path is live and this defect applies.

V8 Link :- #235

Related Jira task/s

SDK-4165 — [Framework- WDIO v8 v9] Builds are getting merged for GRR user for AA session in o11y dashboard

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 buildIdentifier being ignored when the BROWSERSTACK_BUILD_NAME environment variable is set. Successive runs that share a build name are now reported as separate builds (my-build #1, my-build #2) instead of merging into one.

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

• _handleBuildIdentifier no longer treats a set BROWSERSTACK_BUILD_NAME as a reason to skip resolution; the guard keys only on a missing buildName, matching the binary's handleBuildIdentifier and the warning's own wording.
• The skip path now clears this._buildIdentifier, so the unresolved #${BUILD_NUMBER} / ${DATE_TIME} template is no longer sent to TestHub as build_identifier.

Checklist

• Ready to review
• Has it been tested locally?

How this was tested

App Automate (Android, Samsung Galaxy S22 Ultra), buildIdentifier: '#${BUILD_NUMBER}', testObservability: true, BROWSERSTACK_BUILD_NAME exported, same build name across each pair. Framework jasmine so the run takes the classic path. A temporary log line at the launchTestSession call site captured the value actually sent, and was removed before commit.

Run	Build	BROWSERSTACK_BUILD_NAME	build_identifier sent	App Automate build
D1	before fix	set	"#${BUILD_NUMBER}"	sdkFourOneSixFiveMergeDemo
D2	before fix	set	"#${BUILD_NUMBER}"	same build — 08e21249…, 2 sessions
E1	before fix (control)	unset	"#1"	sdkFourOneSixFiveCtrlDemo 1
E2	before fix (control)	unset	"#2"	sdkFourOneSixFiveCtrlDemo 2
F1	after fix	set	"#1"	sdkFourOneSixFiveFixedDemo 1
F2	after fix	set	"#2"	sdkFourOneSixFiveFixedDemo 2

GET /app-automate/builds/08e21249…/sessions.json returns session_count = 2 (19:05:12Z and 19:06:19Z) — the two D runs merged. Each control and each fixed-state build returns session_count = 1.

Re-verified on WDIO v9 (webdriverio@9.31.5): runs G1/G2 under the same conditions produced sdkFourOneSixFiveVNineFixed 1 and 2, and the spurious Skipping buildIdentifier warning is gone.

Unit tests: all 10 _handleBuildIdentifier cases pass, including the pre-existing should delete buildIdentifier if buildName is not present in caps. Two _uploadApp failures in tests/launcher.test.ts are pre-existing — confirmed by re-running that block on an unmodified checkout. npx eslint clean on both changed files.

Note on the existing env-var test

should delete buildIdentifier if BROWSERSTACK_BUILD_NAME is defined as env var passed caps with no buildName, so the !this._buildName branch already covered it and the assertion is unchanged. Only its title was corrected, since the env var was never the operative cause. Two tests were added: one locking resolution when a buildName is present alongside the env var, one asserting the unresolved template is not retained.

PR Validations

Run Tests: Comment RUN_TESTS to trigger sanity tests.

🤖 Generated with Claude Code

[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

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

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 09ebb72c-2b8e-4541-a471-1a6076918f2e

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.}

[harshit-browserstack]

Additional regression check — the binary path (wdio + mocha, where BrowserstackCLI.isRunning() is true and launchTestSession is bypassed).

This is the path the BStackAutomation wdio_mocha wrappers use, and it is the one behaviourally changed by removing the env disjunct: _handleBuildIdentifier now resolves the identifier into the capabilities where it previously deleted it. The concern was a double-applied identifier, since the binary resolves independently.

Post-fix, BROWSERSTACK_BUILD_NAME set, same build name across both runs (webdriverio@9.31.5):

sdkFourOneSixFiveMochaBinFixed  1    hashed=631309094cbe95fd6e4ca88d7c426019d8c9ab36
sdkFourOneSixFiveMochaBinFixed  2    hashed=ade7ced1e4dd354cd2c278bff346a2dbfce0c773

Two distinct builds, one identifier each — no double application, and the spurious Skipping buildIdentifier warning is gone. This matches the pre-fix env-unset control on the same path, which already resolved into caps and behaved correctly.

[harshit-browserstack]

✅ Good to go

File	Confidence
.changeset/pr-192.md	✅ All Clear
packages/browserstack-service/src/launcher.ts	✅ All Clear
packages/browserstack-service/tests/launcher.test.ts	✅ All Clear

Change map (generated deterministically from the diff)

graph LR
  subgraph nwdio_service["wdio-service"]
    npackages_browserstack_service_src_launcher_ts["⚠ launcher.ts<br/>~20 lines"]
    npackages_browserstack_service_tests_launcher_test_ts["⚠ launcher.test.ts<br/>~20 lines"]
    n_changeset_pr_192_md["pr-192.md<br/>~5 lines"]
  end

Loading

↻ 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

[harshit-browserstack]

Re: the v8 gap flagged above — confirmed, _handleBuildIdentifier on the v8 branch has the same guard bug. That's being tracked as a separate PR against v8 (will link here once it's up) rather than bundled
into this one, since it's a different release line with its own changeset.

[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.

[harshit-browserstack]

RUN_TESTS

[harshit-browserstack]

RUN_TESTS

[github-actions]

🔴 SDK PR Review gate is red. Pending:

• The SDK PR Review Agent has not been run on the current head commit yet — run the SDK PR Review Agent (its verdict is advisory; this gate only requires that it ran on the latest commit).

It turns green once the SDK PR Review Agent has run on the current head commit (any verdict — the gate only requires that the review ran). A native reviewer approval is separately required by branch protection before merge.

[harshit-browserstack]

RUN_TESTS

[github-actions]

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

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]

🟢 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.

[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.