fix(cli): send absolute test_file_path and make binary update version-aware (SDK-7233)

[Bhargavi-BS]

What is this about?

WebdriverIO-mocha test results never reached Test Reporting when the customer's project was not a git checkout. The dashboard showed sessions but no tests, and the build never resolved.

Three things, in a chain:

1. test_file_path was gated on a resolvable git root (wdioMochaTestFramework.ts). Outside a git checkout it went out as undefined.
2. The binary dereferences that field in MochaModule.makeFileDetails (path.relative(root, undefined)) and throws before uploadEventData. Every TestRunStarted/TestRunFinished was dropped while CBTSessionCreated still went through — hence sessions present, test rows never resolving. In the reported build: 36 emitted, 0 queued.
3. The binary-side guard for this has shipped since 1.22.x, but affected users never received it. downloadLatestBinary short-circuits when a binary merely exists on disk, never comparing versions. It is only ever reached after the server reports an update, so the binary it finds is stale by construction and the update is skipped on every run — pinning a machine to the first binary it ever downloaded. The reported log shows the 1.48.0 update detected and skipped 1 ms later.

Fixes

• Send the absolute spec path. The binary re-bases it itself against pathProject and versionControlInfo.root (its local is literally named absoluteTestFilePath), so a pre-relativised value also produced a wrong file_name. Sending absolute fixes delivery and the rendered path with no binary change.
• Compare against the target version before short-circuiting the download, preferring the server-reported updated_cli_version so a custom BROWSERSTACK_BINARY_URL (no version in the filename) keeps its peer-race handling instead of re-downloading every run.
• Two latent faults on the same path: a fetch failure left the download promise pending forever (hanging the launcher), and the write stream's error listener was registered after the first await, so an early failure surfaced as an uncaught exception in the user's test process.

Verification — three builds against BrowserStack, same non-git project, all on the customer's exact 1.22.1 binary, only the service package changed:

service	binary	build status	tests reported
unpatched	1.22.1	skipped	0 (one stuck in progress)
patched	1.22.1	passed	1
unpatched	1.48.0	passed	1

The updater fix was verified on the real path too: unpatched left the binary at 1.22.1 (reproducing the reported log line exactly); patched downloaded and landed 1.48.0. file_name now renders as test/specs/smoke/homePage.test.js rather than a ../../../.. path.

1085/1085 tests, tsc --noEmit and eslint clean.

Related Jira task/s

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

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 test results not appearing in Test Reporting for WebdriverIO + Mocha when the project is not a git repository.
• Fixed the BrowserStack binary not updating once a copy was already present, which could leave a machine on an old binary indefinitely.

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

• wdioMochaTestFramework: test_file_path is now the absolute spec path instead of a git-root-relative one (and undefined when no git root). The binary re-bases it against pathProject / versionControlInfo.root, so undefined threw in makeFileDetails and dropped every TestRunStarted/TestRunFinished, and a relative value produced a wrong file_name. Removed the now-dead getGitMetaData() call from both emitter sites.
• cliUtils.downloadLatestBinary: the "binary already exists" short-circuits (post-lock and lock-wait) now require the on-disk binary to match the target version. Previously they tested existence + size only and, since the function is reached only after the server reports an update, always returned the stale binary. Takes updated_cli_version explicitly so a custom BROWSERSTACK_BINARY_URL doesn't lose peer-race handling.
• cliUtils.downloadLatestBinary: processDownload() now has a .catch() (a fetch failure previously left the promise pending forever), and the write-stream error listener moved before the first await (an early stream error had no listener → uncaught exception).

Checklist

• Ready to review
• Has it been tested locally?

PR Validations

Run Tests: Comment RUN_TESTS to trigger sanity tests.

[rounak610]

RUN_TESTS

[minionhelperappqa]

[SDK Wdio Test] TRA build state: failed | Stability 98% — verdict: success. Passed: 83, Failed: 2, Aggregate: 85. TRA: https://observability.browserstack.com/builds/0jfhn295feazexlwljrhhxqehpj3jkbtx8kbofoe

[dandonarahul2002]

verified if getGitMetaData is not used anywhere else?

[rounak610]

yes, verified