Some modified Java files have import blocks that are not in the canonical order produced by the repo’s formatter (google-java-format). This causes CI’s format check to modify files and then fail the job because the working tree is dirty.

CI runs ./go format, which applies google-java-format to all java/**.java files, and then fails if git diff is non-empty.

Run ./go format and commit the resulting changes, or manually reorder imports to match google-java-format output (then re-run ./go format to confirm no changes).

• java/src/org/openqa/selenium/bidi/HasBiDi.java[18-23]
• java/src/org/openqa/selenium/bidi/browser/ClientWindowInfo.java[18-23]
• java/src/org/openqa/selenium/bidi/browser/SetDownloadBehaviorParameters.java[18-27]

addToQueue now always runs Redis cleanup in a finally block via safelyClearRedisState(reqId), and that cleanup calls clearAll(reqId) which deletes completedKey(reqId) and the result:* keys. These keys are required for the “winner-takes-all”/idempotent completion semantics used by complete() and for communicating the terminal result across retries/replicas; deleting them can allow late/duplicate complete() calls to succeed again or return tracked=false, triggering incorrect result overwrites or upstream teardown decisions.

The completion marker (completedKey) is intended to ensure only one terminal completion wins when timeouts race with success and to keep complete() idempotent across retries/replicas via a SET-NX guard. The recent change makes addToQueue exception-safe by always cleaning up Redis state, but the cleanup is now too aggressive because it removes the completion marker and stored result keys, effectively re-opening the request for a second completion in concurrent/failover scenarios.

• java/src/org/openqa/selenium/grid/sessionqueue/redis/RedisBackedNewSessionQueue.java[245-269]
• java/src/org/openqa/selenium/grid/sessionqueue/redis/RedisBackedNewSessionQueue.java[608-636]

RedisBackedNewSessionQueue.addToQueue performs multi-step side effects (registering request state in contexts/waiters, writing Redis keys, pushing a queue entry) but only cleans up that state on the happy path after awaitResult returns. If a Redis operation (or any runtime exception) occurs before the normal cleanup block, the method can exit without removing the in-memory tracking entries and without best-effort cleanup of partially-created Redis keys/list entries, leaking memory and leaving stale queue state.

This is concurrent/resource-heavy, Redis-backed queue code expected to run in failure-prone environments (timeouts, connection resets, closed connections), so cleanup must be bounded and exception-safe across all terminal paths, including partial failures while enqueuing. The current implementation lacks a try/finally to guarantee removal from waiters/contexts, and does not ensure best-effort Redis cleanup when failures happen early.

• java/src/org/openqa/selenium/grid/sessionqueue/redis/RedisBackedNewSessionQueue.java[227-256]

generate_bidi_library always emits bidi-ast.json and bidi-model.json as output filenames. If the macro is ever instantiated more than once in the same Bazel package, Bazel will report output path collisions.

This PR introduces shared artifacts via js_run_binary (*_ast and *_json targets). These outputs are currently fixed strings instead of being scoped by the macro instance name.

• javascript/selenium-webdriver/private/generate_bidi.bzl[157-191]

• Scope outputs by the macro instance name, e.g.:
  • ast_out = name + "-bidi-ast.json" (or name + "_ast.json")
  • model_out = name + "-bidi-model.json"
• Keep the public artifact names stable if needed by adding a thin filegroup (or alias target) that re-exports the uniquely named file under a stable label, rather than a stable filename.

On Windows, Remove-Item -Path $paths ... is called even when $paths is empty (because it’s filtered from env vars only). PowerShell throws a parameter-binding error for an empty collection before -ErrorAction SilentlyContinue can suppress anything, causing the step to fail.

The workflow does not set these env vars explicitly for Windows; the step relies on the runner to provide them.

• scripts/github-actions/delete-browsers-drivers.ps1[12-20]
• .github/workflows/bazel.yml[202-208]

• Add a guard:
  • If $paths.Count -eq 0, print a message and exit 0 (or discover driver locations via Get-Command chromedriver/msedgedriver/geckodriver and delete those paths).
• Optionally: set these env vars in the workflow step (if known stable locations exist), or add fallback known locations used by GitHub Windows runners.

The Windows deletion behavior was narrowed to drivers-only, but the script name still suggests it deletes browsers too.

This is a maintainability/clarity issue (not functional) that could cause confusion later.

• .github/workflows/bazel.yml[205-208]
• scripts/github-actions/delete-browsers-drivers.ps1[1-20]

• Rename the script to delete-drivers.ps1 (or similar) and update the workflow invocation accordingly; or
• Keep the filename but add a short comment in the workflow step noting that the script is drivers-only on Windows.

driver_finder normalizes --browser-binary by stripping surrounding single quotes, but it passes --driver-binary through without stripping. When Service.path contains quotes, DriverFinder validates it with Path(path).is_file() and will fail.

The existing test harness already anticipates quoted executable paths and strips them in other code paths.

• py/test/selenium/webdriver/common/driver_finder_tests.py[46-53]

Normalize the executable path the same way as the browser binary:

executable = request.config.option.executable
exe_path = _resolve_bazel_path(executable).strip("'") if executable else None
service = module.service.Service(executable_path=exe_path)

(Optionally, consider a small helper to avoid duplicating quote-stripping logic.)

The X server (Xvfb) readiness polling loop does not have a deterministic failure path: if xdpyinfo never succeeds within the timeout, the workflow still starts fluxbox in the background and continues, allowing silent/intermittent failures when no display is actually ready.

This step is intended to eliminate a race where fluxbox starts before Xvfb is ready. CI/workflow scripts must validate preconditions and fail safe on errors, and async waits must have explicit timeouts with actionable failure when the timeout is exceeded; without a post-loop assertion, the race is only reduced, not eliminated.

• .github/workflows/bazel.yml[171-182]

UseTransport(Func<ITransport>) validates the factory delegate itself, but not the object it returns. If factory() returns null, BiDi.ConnectAsync will pass it to Broker, leading to a NullReferenceException at runtime.

BiDi.ConnectAsync awaits TransportFactory and immediately constructs Broker(transport, bidi).

• dotnet/src/webdriver/BiDi/BiDiOptionsBuilder.cs[56-63]

Update the wrapper delegate to validate the result:

• Call var transport = factory();
• ArgumentNullException.ThrowIfNull(transport);
• Return Task.FromResult(transport)

Optionally, wrap exceptions from factory() into a faulted Task<ITransport> for consistency with async factory patterns.

The publish matrix currently fails on rerun attempts (github.run_attempt != '1') for the Java matrix entry even when the workflow is releasing a different language (e.g., selenium-4.28.1-ruby). This happens because the Java rerun guard runs before the “is this language selected?” check.

• publish runs a matrix over [java, ruby, dotnet, javascript].
• For patch releases, parse-tag sets outputs.language to the tag suffix (e.g., ruby).
• On reruns, the Java matrix entry should skip when outputs.language != 'java', but it currently fails early.

Move or gate the Java rerun guard so it only triggers when Java is actually being released:

Option A (recommended): nest the Java guard inside the selected-language branch:

if [ "${{ needs.parse-tag.outputs.language == 'all' || needs.parse-tag.outputs.language == matrix.language }}" = "true" ]; then
  if [ "${{ matrix.language == 'java' && github.run_attempt != '1' }}" = "true" ]; then
    echo "::error::Java release is not yet rerun-safe — ..."
    exit 1
  fi
  ./go ${{ matrix.language }}:release
else
  echo skipping
fi

Option B: add the selected-language predicate directly into the Java guard condition.

• .github/workflows/release.yml[144-153]

BiDiOptionsBuilder.UseTransport(ITransport transport) creates a TransportFactory that ignores the CancellationToken parameter (returns a completed task via Task.FromResult(transport)), so BiDi.ConnectAsync(..., cancellationToken) cannot cancel transport acquisition and may even proceed successfully when the token is already cancelled.

BiDi.ConnectAsync forwards the caller’s cancellationToken into builder.TransportFactory(...). The default WebSocket transport factory honors cancellation during connection (e.g., via ClientWebSocket.ConnectAsync), so callers expect consistent .NET cancellation semantics across transport configuration paths; however, the injected transport-instance path currently discards the token.

• dotnet/src/webdriver/BiDi/BiDiOptionsBuilder.cs[53-56]

Update the instance-based factory to observe cancellation before returning the provided transport instance, e.g.:

• implement UseTransport((_, ct) => ct.IsCancellationRequested ? Task.FromCanceled<ITransport>(ct) : Task.FromResult(transport)), or equivalently call ct.ThrowIfCancellationRequested() before returning the transport.

BiDiOptionsBuilder.UseTransport(ITransport transport) does not validate transport and will happily set TransportFactory to return null when the caller passes null, leading to a runtime NullReferenceException downstream.

BiDi.ConnectAsync calls builder.TransportFactory(...) and passes the resulting transport into Broker, which unconditionally calls SendAsync, ReceiveAsync, and DisposeAsync on that instance.

• Add ArgumentNullException.ThrowIfNull(transport); at the start of UseTransport.

• dotnet/src/webdriver/BiDi/BiDiOptionsBuilder.cs[49-58]

scripts/github-actions/delete-browsers-drivers.sh does not use strict mode and runs sudo rm -rf with possibly-empty env-derived paths, without validating that deletions succeeded.

In CI, silent cleanup failures can cause later steps to use unintended system browsers/drivers or run out of disk space without a clear signal.

• scripts/github-actions/delete-browsers-drivers.sh[7-21]

sudo rm -rf is invoked with arguments sourced from environment variables (CHROMEWEBDRIVER, EDGEWEBDRIVER, GECKOWEBDRIVER) without a -- end-of-options marker or validation. If any value begins with -, rm can treat it as an option; combined with another argument like /, this can delete unintended paths.

This script is intended to delete specific preinstalled browser/driver binaries on CI runners, so it should be robust to unexpected env var contents and avoid option injection.

• Build a list/array of paths to delete.
• Filter out empty values.
• Reject dangerous values (/, ., ..) and any value starting with - (or force them to be treated as operands via --).
• Invoke rm as: sudo rm -rf -- "${paths[@]}".

• scripts/github-actions/delete-browsers-drivers.sh[11-21]

AGENTS.md was updated to recommend ./scripts/format.sh / --pre-push to prevent CI formatter failures, but CI currently runs ./go format and reports failures based on that command. This creates inconsistent guidance and a real risk that contributors follow the documented workflow yet still hit CI failures.

• ./go format executes the Rake :format task, which formats across all languages unconditionally.
• ./scripts/format.sh is change-scoped (runs some language formatters only when matching paths changed).
• CI currently enforces formatting by running ./go format (and tells contributors to run it).

Pick one clear source-of-truth and make both CI + docs consistent:

• Update CI workflows to run ./scripts/format.sh (optionally --pre-push) and update error messages to reference it, OR
• Update AGENTS.md to explicitly state CI runs ./go format and recommend ./go format as the fallback/source-of-truth if CI fails.

References:

• AGENTS.md[69-78]
• .github/workflows/ci-lint.yml[47-74]
• Rakefile[128-144]
• scripts/format.sh[1-8], scripts/format.sh[35-137]

Driver._start_local_driver only catches WebDriverException, but driver startup can raise other exception types during the initial NEW_SESSION request path (the HTTP request call site is not wrapped here, and RemoteWebDriver.start_session re-raises the original exception type). As a result, retries may not trigger for common startup-connect failures.

RemoteConnection._request directly calls urllib3 without catching exceptions, and RemoteWebDriver.start_session catches generic Exception only to stop the service and then re-raises the same exception.

• py/conftest.py[467-484]

• Expand the retry handler to catch broader exceptions for local startup (e.g., Exception or a targeted tuple that includes WebDriverException plus networking errors), while still re-raising immediately on the final attempt.
• Keep the warning log including exception type/message to preserve debuggability.

CommandAdditionalMessageDataIsSerializedAsTopLevelFields currently asserts the sent JSON contains the substring {"baz":"qux",, which assumes property ordering (that baz is first) and a trailing comma. In reality, the message writer serializes id, method, and params first, then appends CommandOptions.AdditionalMessageData fields after params, so baz will typically not be at the start and may be the last property (no trailing comma), making the test fail even when serialization is correct.

This is a new/updated unit test intended to validate that CommandOptions.AdditionalMessageData is serialized into the top-level command envelope. To satisfy the required test coverage (PR Compliance ID 18) without brittleness, the assertion should validate the semantic behavior (a top-level property baz with value qux) in an order/format-independent way, e.g., by parsing the outgoing JSON or by using a substring match that doesn’t depend on ordering or commas.

• dotnet/test/webdriver/BiDi/SessionUnitTests.cs[158-170]

AdditionalData(string json) currently accepts any valid JSON, but AdditionalData is used as a property-bag (object) for extension properties. When callers provide a valid non-object JSON (e.g., "null", "[]", "123"), IsEmpty becomes true and the data is silently dropped (never merged/sent).

The API surface suggests the string overload is a convenience for providing additional properties. Silent dropping is surprising and makes debugging extensions difficult.

In AdditionalData(string json), validate doc.RootElement.ValueKind == JsonValueKind.Object.

• If not an object, throw ArgumentException (or JsonException) with a clear message (e.g., "AdditionalData JSON must be an object").

• dotnet/src/webdriver/BiDi/AdditionalData.cs[39-43]

AdditionalData.TryGetValue should follow the .NET Try-pattern and never throw for an empty value. Currently, AdditionalData.Empty is default (non-object JsonElement), but TryGetValue calls _data.TryGetProperty(...) unconditionally.

IsEmpty is defined as _data.ValueKind != JsonValueKind.Object, meaning Empty/default instances are explicitly non-object, yet TryGetValue does not check IsEmpty (or ValueKind) before accessing object-only APIs.

• dotnet/src/webdriver/BiDi/AdditionalData.cs[62-66]

Implement:

• if (IsEmpty) { value = default; return false; }
• otherwise call _data.TryGetProperty(key, out value)

Optionally also guard the indexer similarly (or leave it throwing by design, but ensure TryGetValue is safe).

CommandOptions.AdditionalData is defined as part of the public options surface, but it is never applied to the serialized command params. As a result, options-based additional params data is silently dropped, and callers cannot practically use params-level extension data because the concrete *Parameters types are internal and created inside modules.

Broker.ExecuteAsync serializes only @params as "params", and only uses options.AdditionalMessageData for envelope-level additions.

• dotnet/src/webdriver/BiDi/Broker.cs[68-109]
• dotnet/src/webdriver/BiDi/Command.cs[50-59]

• In Broker.ExecuteAsync (centralized fix): if options?.AdditionalData is non-empty, merge it into @params.RawAdditionalData (or set @params.AdditionalData via the backing RawAdditionalData) before calling JsonSerializer.Serialize.
• Define merge behavior for key collisions (preferably throw a clear exception if the same key already exists in @params.RawAdditionalData).
• Add/adjust tests to assert that options.AdditionalData appears inside the serialized params object.

AdditionalMessageData is appended to the outgoing command envelope as arbitrary root-level JSON properties. Without validation, callers can provide keys like id, method, or params, producing duplicate JSON property names and potentially breaking protocol semantics and command correlation.

Outgoing envelope already writes id, method, and params before iterating AdditionalMessageData.

• dotnet/src/webdriver/BiDi/Broker.cs[95-109]

• Add a reserved-name check before writing each AdditionalMessageData entry.
  • At minimum reject: id, method, params.
  • Consider also rejecting other envelope keys that appear in incoming messages: type, result, error, message.
• On collision, throw an ArgumentException (or similar) with a clear message so failures are deterministic and debuggable.
• Add unit/serialization tests ensuring reserved keys are rejected and non-reserved keys serialize correctly.

A whitespace-only blank line was introduced, which may violate repo formatting standards and be modified by the formatter.

The new line in AdditionalData(string json) appears to contain indentation/trailing whitespace on an otherwise blank line.

• dotnet/src/webdriver/BiDi/AdditionalData.cs[47-47]

CanGetStatusWithAdditionalData() currently acts as a smoke test (it only asserts status is non-null) and does not verify the PR’s intended behavior that AdditionalData/AdditionalMessageData are actually serialized onto the wire and/or propagated, so the feature it claims to test can regress without failing.

PR Compliance ID 19 expects meaningful coverage for changed behavior; this PR adds support for serializing/propagating extra JSON properties, but the test would still pass even if the additional data is ignored/dropped. Since StatusAsync talks to a real remote end, the response may not echo extension fields, so validating serialization typically requires inspecting the outgoing message (e.g., via a stub/mock transport or a broker-level unit test), or alternatively renaming the test to reflect that it only verifies the call succeeds without error.

• dotnet/test/webdriver/BiDi/Session/SessionTests.cs[46-59]

Broker.ExecuteAsync currently applies options.AdditionalData by mutating the caller-provided @params.RawAdditionalData prior to serialization, creating observable side effects and potential races if parameters are reused or accessed concurrently. Separately, Parameters.RawAdditionalData is publicly readable and exposes a mutable Dictionary<string, JsonElement>, allowing callers to mutate command inputs after construction, undermining the compliance requirement for immutable command option/input surfaces.

PR Compliance ID 8 requires command option/input types to be immutable from the public API surface to prevent post-creation mutation from affecting execution/serialization. Even if CommandOptions is init-only, mutating the provided parameters during send makes behavior non-deterministic when parameter instances are cached, reused, or concurrently accessed; exposing a mutable dictionary via a public getter similarly enables external mutation after the command parameters have been created or handed off.

• dotnet/src/webdriver/BiDi/Broker.cs[100-107]
• dotnet/src/webdriver/BiDi/Command.cs[38-40]

ci-build.sh now runs all tests (//...) under --config=rbe-ci without excluding the targets that were previously being deselected for RBE CI. Because test:rbe only filters -skip-rbe, any RBE-incompatible targets that are not tagged skip-rbe will now execute on RBE.

• test:rbe uses --test_tag_filters=-skip-rbe and does not exclude requires-network.
• Selenium browser test rules commonly include requires-network (via COMMON_TAGS) and are frequently generated by macros (Java selenium_test, Ruby rb_integration_test), so the safest replacement for the removed deselection list is to tag the formerly-deselected targets (or split suites) with skip-rbe.

• scripts/github-actions/ci-build.sh[15-20]
• .bazelrc.remote[35-37]
• common/browsers.bzl[1-8]
• java/private/selenium_test.bzl[22-56]
• java/test/org/openqa/selenium/chrome/BUILD.bazel[26-47]
• rb/spec/tests.bzl[181-257]
• py/BUILD.bazel[64-76]

1. Preferred: Add skip-rbe tags to the specific targets that were previously deselected (may require splitting macros/suites so only those targets get the tag).
2. Temporarily restore an explicit exclusion mechanism in CI until tagging is completed.
3. If intentional, update RBE filtering logic to exclude the appropriate tag(s) (e.g., requires-network)—but only if that matches desired CI coverage.

openSocket() now embeds the raw URI in several ConnectionFailedException messages, but does not apply the existing maskUrlCredentials(...) logic used elsewhere in this class. This can leak embedded credentials when URIs contain userInfo.

• maskUrlCredentials is already implemented and used in other error paths.
• messages.getRawUri(req) returns URI.create(rawUrl) with userInfo intact.

• Wrap URIs in maskUrlCredentials(...) before interpolating into exception messages.

• Avoid calling messages.getRawUri(request) inside the URISyntaxException catch in a way that could throw a new exception; use a safe fallback (e.g., request.getUri()), then mask.

• java/src/org/openqa/selenium/remote/http/jdk/JdkHttpClient.java[157-262]

• java/src/org/openqa/selenium/remote/http/jdk/JdkHttpClient.java[516-546]

• java/src/org/openqa/selenium/remote/http/jdk/JdkHttpMessages.java[123-147]

driver_finder_spec is configured with tags = ["os-sensitive"], but the rb_integration_test macro treats os-sensitive as a browser-filtered tag. As a result, the driver_finder_spec-{chrome,firefox,ie} targets won’t actually receive the os-sensitive tag, making tag filtering inconsistent across browser variants.

• rb/spec/integration/selenium/webdriver/BUILD.bazel adds a dedicated rb_integration_test stanza for _NO_GRID with tags = ["os-sensitive"].
• rb/spec/tests.bzl filters os-sensitive to only apply to chrome-beta, edge, firefox-beta, and safari.

Choose one of these approaches:

1. If driver_finder_spec should be os-sensitive for all browsers, use a universal tag (one that is not filtered) or adjust tag filtering to include all browsers this target runs on.
2. If it is only os-sensitive for some browsers, set tags in a way that matches the intended browsers (e.g., update _BROWSER_TAG_FILTERS["os-sensitive"] or use a new tag name).

• rb/spec/integration/selenium/webdriver/BUILD.bazel[65-76]
• rb/spec/tests.bzl[169-179]

driver_finder_spec.rb excludes browser: :edge from the "downloads the browser into the Selenium cache" example. Since the spec target is executed for Edge via the Bazel browser matrix, this prevents validating browser-download caching behavior for Edge at all.

The guard system supports combining multiple conditions (e.g., browser + platform), and the suite already provides :platform and :browser conditions.

• rb/spec/integration/selenium/webdriver/driver_finder_spec.rb[54-56]

Decide the intended behavior:

• If Edge should only be excluded on specific platforms (e.g., Windows where Edge may already be present), make the exclusion conditional, e.g. add platform: :windows (or the relevant platform(s)).
• Otherwise, remove :edge from the exclusion list and/or update the guard reason to reflect the actual rationale for excluding Edge from browser-download caching verification.

includes_path? prints a warn "DEBUG ..." line unconditionally, which pollutes integration test output.

This helper is used by the new DriverFinder integration spec and will be called repeatedly across the browser matrix, so the debug output will be amplified in CI.

• rb/spec/integration/selenium/webdriver/spec_support/helpers.rb[149-151]

Remove the warn line entirely, or guard it behind an opt-in flag (e.g., if ENV['SE_DEBUG_INCLUDES_PATH'] == 'true') so normal CI runs are silent.

includes_path? currently mixes Windows normalization (via Platform.unix_path, which normalizes to OS separators) with a hard-coded '/' prefix check. On Windows this makes the check always return false.

• Platform.unix_path normalizes by converting File::ALT_SEPARATOR to File::SEPARATOR. On Windows, that converts / to \\.
• includes_path? then assumes / separators when doing start_with?("#{root}/").

• rb/spec/integration/selenium/webdriver/spec_support/helpers.rb[146-150]

Update includes_path? to normalize both path and root to a consistent separator before comparing, e.g.:

• Convert backslashes to forward slashes using tr('\\', '/') (works cross-platform).
• File.expand_path both values to avoid relative-path surprises.
• On Windows, consider case-insensitive comparison for drive letters (downcase) before start_with?.

Example implementation:

def includes_path?(path, root)
  path = File.expand_path(path).tr('\\', '/')
  root = File.expand_path(root).tr('\\', '/').chomp('/')
  if WebDriver::Platform.windows?
    path = path.downcase
    root = root.downcase
  end
  path.start_with?("#{root}/")
end

pkg_archive always deletes the expanded package directory (pkg_name) at the end. Since move is optional, a caller can legally omit it, in which case nothing is moved out and the extracted tree is deleted, leaving an empty external repository.

The rule’s attrs define move as a non-mandatory attr.string_dict(), so an empty dict is a valid configuration.

• common/private/pkg_archive.bzl[50-59]
• common/private/pkg_archive.bzl[60-71]

• Always delete the downloaded archive (download_name).
• Only delete the expanded directory (pkg_name) if move is non-empty (i.e., you actually moved desired artifacts out), or make move mandatory / explicitly fail() when move is empty so the rule can’t silently delete everything.

check_error_with_driver_in_path() has changed fallback semantics: it now propagates errors when *is_driver_in_path is true but get_browser_path() is non-empty, whereas previously driver-in-PATH mode would swallow these errors and continue. Because browser_path is frequently populated by auto-detection (not just explicit user input like --browser-path), this additional predicate can cause setup flows that intend to fall back to a PATH driver to abort during later failures (e.g., driver version discovery), creating a breaking behavior change for upgrades.

• setup() computes use_driver_in_path based on detecting a driver in PATH and the original browser version being empty, then routes errors from discovery/download/version steps through check_error_with_driver_in_path().
• Browser discovery/version logic calls detect_browser_path() when browser_path is empty; detect_browser_path() updates configuration via set_browser_path(), so get_browser_path() reflects derived/auto-detected state, not solely user-provided state.
• The PR’s main goal is switching command execution to argv, but this extra gating changes error/fallback semantics relied on by use_driver_in_path flows and may violate the “no breaking changes on upgrade” requirement.

• rust/src/lib.rs[804-854]
• rust/src/lib.rs[950-964]

The trace log *** Browser path {} is emitted before detect_browser_path() is called, so it always shows the raw (often empty) value from get_browser_path() rather than the resolved path that will actually be used.

In general_discover_browser_version, browser_path starts as self.get_browser_path().to_string() (empty when no --browser-path flag is given). The trace is logged immediately, then detect_browser_path() may populate it. The trace should reflect the final resolved path.

• rust/src/lib.rs[1175-1181]: Move the .trace(...) call to after the if browser_path.is_empty() block (i.e., after line 1181), so it logs the path that will actually be used for version probing.

general_discover_browser_version now builds a direct std::process::Command with args = [cmd_version_arg]. However, current callers pass DASH_VERSION / DASH_DASH_VERSION, which are format templates (contain {} placeholders) and were previously only safe because the old code formatted them into a full command string before going through sh -c.

This makes non-Windows browser version discovery invoke the browser with an invalid literal argument like "{}{}{} --version".

• DASH_VERSION / DASH_DASH_VERSION are currently defined as format templates.
• Chrome/Edge/Firefox pass these constants into general_discover_browser_version.
• The non-Windows path now directly uses cmd_version_arg.to_string() as an argv value.

• rust/src/lib.rs[87-88]
• rust/src/lib.rs[1169-1211]
• rust/src/chrome.rs[281-287]
• rust/src/edge.rs[165-189]
• rust/src/firefox.rs[194-200]

Option A (minimal): Change the constants to be actual flags:

• DASH_VERSION = "-v"
• DASH_DASH_VERSION = "--version"

Option B (API cleanup): Change general_discover_browser_version to accept Vec<String> (or &[&str]) for version args, and update each manager to pass vec!["--version".into()] (or vec!["-v".into()]).

.github/workflows/gh-cache.yml uses a push.paths filter to decide when to repopulate the GitHub cache, but it does not include key dependency inputs (pnpm-lock.yaml, multitool.lock.json) that are used by Bazel to generate external repositories. This means macOS/Windows cache population will not run when those files change, leaving caches stale.

MODULE.bazel references both //:multitool.lock.json (rules_multitool hub) and //:pnpm-lock.yaml (npm_translate_lock). These files directly affect what external assets Bazel will download.

• .github/workflows/gh-cache.yml[4-15]

Add the missing files to the on.push.paths list (at minimum pnpm-lock.yaml and multitool.lock.json). Consider also including other npm-related inputs referenced by npm_translate_lock (e.g. package.json, pnpm-workspace.yaml, .npmrc, and relevant javascript/**/package.json) if you want cache population to run immediately when those change.

Selenium::WebDriver::Safari::Options defines a browser_name= setter in Ruby, but the RBS signature file does not declare this method. This creates a mismatch between runtime API and the typed interface.

The PR introduced/updated Safari::Options#browser_name= in Ruby, and updated the RBS to include browser_name, but the setter signature was not added.

• rb/lib/selenium/webdriver/safari/options.rb[39-45]
• rb/sig/lib/selenium/webdriver/safari/options.rbs[13-16]

Add a setter signature in rb/sig/lib/selenium/webdriver/safari/options.rbs, e.g.:

• def browser_name=: (String value) -> void (or return String if you want to model Ruby’s assignment return value).

The DriverFinder env-precedence spec sets ENV['SE_CHROMEDRIVER'] and then unconditionally calls ENV.delete('SE_CHROMEDRIVER') in ensure, which can wipe a pre-existing value from the parent environment and leak state across examples.

This test is intended to validate env-var precedence, but to comply with the expectation that test changes are reliable across environments (PR Compliance ID 13) and to avoid order-dependent failures, it should not permanently mutate global process environment. Other unit specs in this repo follow a safer pattern by preserving/restoring prior env values rather than always deleting them.

• rb/spec/unit/selenium/webdriver/common/driver_finder_spec.rb[36-48]

Safari.path now memoizes nil, changing the public method’s behavior so it no longer provides a default Safari path nor performs early validation/OS checks. This is a backward-incompatible, user-visible behavior change.

Safari.path is a public singleton method. With the new implementation, any caller expecting a default path (or early, actionable errors) will instead receive nil and may fail later with less clear errors.

• rb/lib/selenium/webdriver/safari.rb[48-50]

• Reintroduce the previous default path and validation/error behavior (e.g., default to the Safari binary on macOS and raise a clear WebDriverError when unsupported/unavailable).
• If the new nil default is intentional, add a deprecation path and update callers/documentation accordingly so upgrades do not silently change behavior.

Selenium::WebDriver::Service#env_path was removed from the Ruby implementation without a deprecation path, but the corresponding RBS signature still declares it, creating an API break for callers and leaving the type/signature contract out of sync with runtime behavior.

• The Ruby signature file still exposes env_path as a public method (def env_path).
• The Service implementation no longer defines env_path, so existing callers will hit NoMethodError at runtime.
• The mismatch will also fail RBS/Steep (or other signature validation) because the method is declared but not implemented.
• Compliance requires maintaining API compatibility and deprecating public functionality before removal.

• rb/lib/selenium/webdriver/common/service.rb[89-105]
• rb/sig/lib/selenium/webdriver/common/service.rbs[48-60]

DriverFinder now checks an environment variable (DRIVER_PATH_ENV_KEY) when resolving the driver path, but there is no unit test asserting this precedence and behavior.

There are existing unit tests for DriverFinder behavior (class path, proc path, Selenium Manager calls), so adding a small/unit test for ENV precedence is feasible and keeps tests aligned with the changed behavior.

• rb/lib/selenium/webdriver/common/driver_finder.rb[50-68]
• rb/spec/unit/selenium/webdriver/common/driver_finder_spec.rb[24-99]

Service#initialize no longer reads the driver-path environment variable (e.g., SE_CHROMEDRIVER) to populate @executable_path. The repo’s unit specs currently assert that Service.new.executable_path is derived from the env var, so the change will cause test failures and breaks the previously-tested behavior.

The env-var lookup was removed from Service#initialize and moved into DriverFinder. That makes env vars apply later (when DriverFinder runs), but it also means service.executable_path stays nil after construction.

Choose one consistent behavior and align code + tests:

• Preserve existing behavior (least breaking): make Service#executable_path (reader) fall back to ENV when @executable_path is nil (or re-introduce env assignment in initialize).
• If behavior change is intended: update the affected unit specs to assert env usage via DriverFinder or Service#launch, not via Service#executable_path immediately after new.

Relevant locations:

• rb/lib/selenium/webdriver/common/service.rb[69-92]
• rb/spec/unit/selenium/webdriver/chrome/service_spec.rb[153-173]
• rb/spec/unit/selenium/webdriver/safari/service_spec.rb[118-138]
• rb/spec/unit/selenium/webdriver/edge/service_spec.rb[163-183]
• rb/spec/unit/selenium/webdriver/firefox/service_spec.rb[215-236]
• rb/spec/unit/selenium/webdriver/ie/service_spec.rb[153-173]
• rb/spec/unit/selenium/webdriver/common/driver_finder_spec.rb[22-99]

The script only lists up to 100 caches and prunes within that partial set, which can leave most stale caches untouched once the repository accumulates more than 100 CodeQL caches.

The script comments say CodeQL creates a new overlay-base-database cache per commit; on an active repository, that can exceed 100 entries quickly.

• scripts/github-actions/prune-codeql-caches.sh[3-6]
• scripts/github-actions/prune-codeql-caches.sh[24-28]

• Replace the single gh cache list ... --limit 100 call with logic that retrieves all matching caches.
  • Option A: increase --limit to the maximum supported by gh (if sufficiently high for this repo’s scale).
  • Option B (more robust): implement pagination via the GitHub API (gh api) to iterate through all pages of caches, building the rows array from the full result set.
• Keep the rest of the grouping/deletion logic unchanged so behavior stays “keep newest per group”.

scripts/github-actions/disk-status.sh is sourced from workflow steps. Inside measure(), the du pipelines can exit non-zero (e.g., when $path/* doesn’t match because the directory is empty, or due to permissions). When sourced, that failure can propagate and fail the workflow step.

This script is intended for diagnostics only; it should be best-effort and never fail CI.

• scripts/github-actions/disk-status.sh[29-37]
• .github/workflows/bazel.yml[206-214]
• .github/workflows/bazel.yml[239-247]
• .github/workflows/bazel.yml[293-300]

with_env mutates ENV but its cleanup unconditionally deletes keys, which can remove pre-existing environment variables and leak global state changes across tests.

New tests added in default_spec.rb rely on with_env to set http_proxy and no_proxy/NO_PROXY. The helper currently deletes those keys in ensure rather than restoring prior values (or leaving them unset only if they were originally absent).

• rb/spec/unit/selenium/webdriver/spec_helper.rb[38-43]
• rb/spec/unit/selenium/webdriver/remote/http/default_spec.rb[127-139]

DriverFinder.toArguments() reads the se:browserName capability via an unchecked cast to String. Since capability values are Object and may be protocol-/user-provided (including the new Electron override), a non-String value can trigger a ClassCastException, breaking Selenium Manager-based driver discovery instead of producing a deterministic, actionable validation failure or a safe fallback.

Capabilities are externally influenced (protocol/user) and getCapability() returns Object, so DriverFinder should validate type and null/emptiness before using se:browserName. When the value is absent/invalid, it should either ignore it and fall back to options.getBrowserName(), or throw a clear IllegalArgumentException describing the expected type/value; optionally, if the value is present but not a String, log a warning and ignore it.

• java/src/org/openqa/selenium/remote/service/DriverFinder.java[133-138]

DriverFinder.toArguments() uses options.getClass().getName().toLowerCase().contains("electron") to decide whether to pass --browser electron to Selenium Manager. This is brittle: it fails for subclasses/wrappers (false negatives) and can misclassify unrelated capabilities classes (false positives).

DriverFinder accepts a generic Capabilities instance, so relying on the implementation type name is not a stable contract.

• java/src/org/openqa/selenium/remote/service/DriverFinder.java[133-138]
• java/src/org/openqa/selenium/chrome/ElectronOptions.java[46-64]
• java/test/org/openqa/selenium/remote/service/DriverFinderTest.java[198-218]

1. Add an explicit, Selenium-namespaced marker capability in ElectronOptions (e.g., se:electron = true) and ensure it survives merge().
2. Update DriverFinder.toArguments() to check that marker (e.g., Boolean.TRUE.equals(options.getCapability("se:electron"))) instead of class-name matching.
3. Update/add tests:
   • Existing ElectronOptions test should assert the marker capability is present.
   • DriverFinderTest should assert --browser electron is sent when the marker is present, and that wrapping in ImmutableCapabilities still works.

A workflow_dispatch string input (inputs.targets) is user-controlled and later inserted directly into a bazel test shell command, allowing shell metacharacters (e.g., ;, &&) to be interpreted as commands.

This workflow now accepts targets via manual dispatch. The value is used in the os-tests job’s run script, so it must be handled as data (arguments) rather than executable shell text.

• .github/workflows/ci-ruby.yml[10-15]
• .github/workflows/ci-ruby.yml[73-80]

• Read inputs.targets into a variable inside quotes.
• Split into a bash array safely (e.g., read -r -a targets_arr <<< "$targets").
• Invoke Bazel with "${targets_arr[@]}" so each target is a separate argument and shell metacharacters are not executed.
• Optionally validate that each entry matches expected Bazel target patterns (e.g., starts with //).

The Windows os-tests matrix entry tries to exclude IE by adding -ie, but IE remote targets use the tag ie-remote and inherit skip-rbe, so they still match the positive filters.

rb_integration_test generates both local and *-remote test targets, and remote targets inherit the browser-specific tag list (including skip-rbe for IE).

• .github/workflows/ci-ruby.yml[57-60]

Update the Windows tag-filters to also exclude the remote IE tag, e.g.:

• edge,edge-remote,unit,skip-rbe,-ie,-ie-remote

(Alternatively, remove skip-rbe from the Windows include list if it is not intended to pull in unrelated skip-rbe tests.)

process_binding() uses grep inside a command substitution without guarding for the “no matches” exit code. When no Ruby targets exist, this can terminate the step early and fail CI.

The workflow should continue and simply omit rb_targets when there are no matching targets.

• .github/workflows/ci.yml[81-100]

• Make the pipeline tolerant of no matches, e.g. append || true to the whole pipeline, or use grep ... || :.
  • Example:
    • lang_targets=$(echo "$targets" | tr ' ' '\n' | grep -E "^${pattern}[:/]" | tr '\n' ' ' | sed 's/ *$//' || true)
• Consider switching echo to printf '%s\n' "$targets" to avoid echo edge cases.

os-tests references inputs.targets, but targets is only declared for workflow_call. For workflow_dispatch runs, this input is not defined, so the Bazel command may receive no explicit targets.

The workflow declares workflow_dispatch: with no inputs, but still relies on inputs.targets.

• .github/workflows/ci-ruby.yml[3-11]
• .github/workflows/ci-ruby.yml[47-76]

Add workflow_dispatch.inputs.targets mirroring the workflow_call input (same default //rb/...), or change the command to fall back to //rb/... when inputs.targets is empty.

The os-tests Bazel invocation converts exit code 4 into success (exit 0). This can hide “no tests found” situations caused by incorrect target selection or tag filters, resulting in false-green CI.

bazel test exit code 4 typically indicates that no tests were executed. Treating this as success in PR CI can allow Ruby changes to merge without test coverage.

• .github/workflows/ci-ruby.yml[74-76]

matrix.browser is set to YAML boolean true for ubuntu/windows, then forwarded to reusable workflow input browser which is typed as string. This risks workflow-call validation errors and also changes behavior of steps gated on inputs.browser != ''.

The called workflow declares browser as type: string.

• .github/workflows/ci-ruby.yml[52-66]
• .github/workflows/bazel.yml[19-28]

• Change browser: true to a string value:
  • If you want “no specific browser but enable UI setup”, use browser: 'enabled' (string) and update bazel.yml docs accordingly.
  • If you actually intend Edge on Windows, set browser: 'edge'.
  • If Ubuntu is unit-only, set browser: '' and adjust tag filters accordingly.
• Keep macOS as browser: safari for safaridriver enablement.

ArgumentNullException.ThrowIfNull(descriptors) is ineffective for ImmutableArray<T> parameters because ImmutableArray<T> is a struct (non-nullable value type). This can hide the real validation intention and doesn’t provide a clear exception for empty/default arrays.

The affected APIs are public entry points (IBiDi / BiDi) for multi-descriptor subscription/stream creation.

• Replace ThrowIfNull(descriptors) with explicit validation for default/empty immutable arrays (e.g., descriptors.IsDefaultOrEmpty or descriptors.Length == 0) and throw ArgumentException with a clear message.

• Apply the same validation to both SubscribeAsync(... ImmutableArray<EventDescriptor> ...) overloads and StreamAsync(... ImmutableArray<EventDescriptor> ...).

• dotnet/src/webdriver/BiDi/BiDi.cs[104-132]

DriverTestFixture currently calls driver.Dispose() in [OneTimeTearDown] and in ResetOnError(). Because the driver is owned/tracked by EnvironmentManager (singleton), disposing the driver directly can leave EnvironmentManager holding a disposed instance and cause later calls to reuse or quit a disposed driver.

• EnvironmentManager.GetCurrentDriver() returns the cached driver field if non-null.
• EnvironmentManager.CloseCurrentDriver() is the method that both quits the driver and clears the cached reference (driver = null).

• dotnet/test/webdriver/DriverTestFixture.cs[128-148]

1. In DriverTestFixture.TearDown() (the [OneTimeTearDown]), replace driver?.Dispose(); with EnvironmentManager.Instance.CloseCurrentDriver(); (and optionally set driver = null; for clarity).
2. In ResetOnError(), remove the explicit driver?.Dispose(); and just call driver = EnvironmentManager.Instance.CreateFreshDriver(); (since CreateFreshDriver() already closes the current driver via CloseCurrentDriver()).
3. Ensure there is no remaining path where EnvironmentManager.driver can remain non-null while the underlying driver is disposed.

dotnet build/pack of Selenium.Support.csproj is now cross-targeting (net462/netstandard2.0/net8.0). Because it has a ProjectReference to Selenium.WebDriver.csproj, WebDriver is built per target framework, and WebDriver’s GenerateBazelArtifacts target executes bazel build ... before every CoreCompile.

This leads to redundant Bazel builds (previously Support was single-TFM), significantly increasing build time and increasing exposure to intermittent Bazel/env failures during normal MSBuild workflows.

• Support is now multi-targeted and project-references WebDriver.
• WebDriver runs Bazel generation unconditionally in a BeforeTargets="CoreCompile" target.

• Gate Bazel generation so it runs once per multi-target build (outer build) while still running for single-TFM builds.
• A typical approach is to:
  • Add a target that runs when $(IsCrossTargetingBuild) == 'true' (outer build) before inner builds dispatch, generating artifacts once.
  • Keep a separate path for single-target builds ($(IsCrossTargetingBuild) != 'true') that runs before CoreCompile.
• Ensure generated files exist before compilation in all cases.

Fix focus areas (files/lines):

• dotnet/src/support/Selenium.Support.csproj[3-41]
• dotnet/src/webdriver/Selenium.WebDriver.csproj[62-69]

The detect-branch job calls git ls-remote ... origin ... even though no repository checkout (or equivalent remote setup) occurs, so origin is undefined and the branch-existence detection becomes unreliable; this can incorrectly skip downstream evaluate/commit-pins/promote jobs.

detect-branch runs on a fresh GitHub-hosted runner; without actions/checkout, there is no local git repository and no configured remote named origin, so git ls-remote origin ... can fail or yield incorrect results. Other jobs/workflows that successfully use git ls-remote ... origin do so after actions/checkout, which configures origin, indicating the missing prerequisite here.

• .github/workflows/renovate-dependency-pr.yml[25-44]
• .github/workflows/renovate-dependency-pr.yml[40-44]

The detect-branch step writes exists=... to $GITHUB_OUTPUT using a command substitution containing nested, unescaped double-quotes (via echo "true" / echo "false" inside an outer echo "exists=$(...)"), which can break shell parsing and prevent the exists output from being set, causing downstream jobs gated on this value to skip or fail.

This is part of a CI workflow and must be robust and deterministic (per PR Compliance ID 17) to avoid silent failures or broken runs. The problematic pattern is effectively echo "exists=$( ... && echo "true" || echo "false")", where the inner quotes can prematurely terminate the outer string; downstream logic depends on needs.detect-branch.outputs.exists being 'true' for the evaluate job (and related evaluation/pinning/promotion) to run.

• .github/workflows/renovate-dependency-pr.yml[35-46]

The promote step uses ${{ secrets.SELENIUM_CI_TOKEN }} directly even though the secret is declared required: false, so the token may be empty and PR creation will fail.

Other workflows (including this PR’s renovate job and the reusable commit-changes.yml) already use a || github.token fallback.

• .github/workflows/renovate-dependency-pr.yml[14-17]
• .github/workflows/renovate-dependency-pr.yml[78-83]

Either:

• Change to token: ${{ secrets.SELENIUM_CI_TOKEN || github.token }} in the create-pull-request step, or
• Mark SELENIUM_CI_TOKEN as required: true if fallback is not acceptable.

The workflow assumes temp/bazel-updates exists and reflects the current base-ref, but the branch is only pushed when changes.patch is non-empty. If there are no Bazel update changes, the branch is not pushed/created, yet the Renovate job still checks it out.

• bazel.yml deletes changes.patch when empty.
• commit-changes.yml skips commit/push when changes.patch is empty.
• renovate-dependencies.yml always checks out temp/bazel-updates.

• .github/workflows/renovate-dependencies.yml[36-63]
• .github/workflows/commit-changes.yml[46-56]
• .github/workflows/bazel.yml[274-287]

Ensure temp/bazel-updates is force-updated to the current base-ref even when there are no patch changes, for example:

• Update commit-changes.yml to still git push --force origin HEAD:"$PUSH_BRANCH" in the else branch (no patch), or
• Add a dedicated step/job in renovate-dependencies.yml that force-pushes inputs.base-ref to temp/bazel-updates when no patch is present, and gate the Renovate checkout accordingly.

The reusable workflow checks out inputs.ref || github.ref but defaults PUSH_BRANCH to inputs.push-branch || github.ref_name, which may not match the ref actually checked out (notably on pull_request, where github.ref_name can be a merge ref name). This can cause the workflow to run git push --force origin HEAD:"$PUSH_BRANCH" against the wrong branch.

• The workflow checks out ${{ inputs.ref || github.ref }} but sets PUSH_BRANCH: ${{ inputs.push-branch || github.ref_name }}; if a caller provides inputs.ref that differs from the called workflow run’s github.ref_name, the push target becomes incorrect.
• ci-lint.yml calls commit-changes.yml on PRs with ref: ${{ github.event.pull_request.head.ref }} and does not set push-branch, so the called workflow uses the problematic default.

• .github/workflows/commit-changes.yml[39-40]
• .github/workflows/commit-changes.yml[53-53]
• .github/workflows/commit-changes.yml[59-59]
• .github/workflows/commit-changes.yml[39-59]

The workflow currently checks only file size (-s) and exits 0 when the patch is missing/empty. With continue-on-error: true on the download step, an actual artifact download failure can be silently treated as a successful no-op.

This reusable workflow is invoked from release/CI workflows where a missing patch may indicate an upstream failure or wrong artifact name.

• .github/workflows/commit-changes.yml[41-59]

• Emit a ::notice:: before exiting when no patch is present.
• Optionally, distinguish:
  • if [ ! -f changes.patch ]; then ... (artifact missing)
  • elif [ ! -s changes.patch ]; then ... (empty patch) and decide whether “missing” should fail or remain a no-op based on intended caller behavior.
• If you want to keep it as a no-op, at minimum log clearly that commit/push is being skipped due to missing/empty patch.

The workflow output changes-committed is documented as representing whether changes were "committed and pushed", but the step output is derived solely from whether a commit occurred. With the current logic, a push can occur while committed=false, violating the output contract.

• Output documentation indicates both commit and push.
• Push can happen even without a commit when PUSH_BRANCH is set.

• .github/workflows/commit-changes.yml[24-27]
• .github/workflows/commit-changes.yml[58-69]

• Either:
  1. Change logic so committed becomes true only after a successful push (and ensure push is only attempted when appropriate), or
  2. Update the output description/name (and optionally add a separate pushed output) so consumers can reliably detect what happened.

The workflow currently runs git push --force origin HEAD:"$PUSH_BRANCH" whenever PUSH_BRANCH is set, even if changes.patch is missing/empty and no commit was created. This can rewrite the remote branch pointer and clobber remote history (accidental data loss), particularly when the patch artifact download fails but the job continues.

• The workflow tracks whether it created a commit via a committed=false/true flag, but the push-to-PUSH_BRANCH path is not conditioned on committed.
• The patch/artifact download is allowed to fail (continue-on-error: true), and commits occur only when changes.patch exists/is non-empty.
• As a result, setting inputs.push-branch can cause a force-push of the current HEAD even when this run produced no changes (or the artifact was missing), effectively resetting/overwriting the target branch.

• .github/workflows/commit-changes.yml[47-69]

node:install now computes pkg_dir via File.expand_path(...) and passes it to Bazel.execute as --dir <path>. On Windows, Bazel.execute assembles a single command line with cmd.join(' ') (no quoting), so any space-containing path will break argument parsing.

This change introduces a new space-sensitive argument (--dir) that was not present previously.

• rake_tasks/node.rake[117-118]
• rake_tasks/bazel.rb[26-32]

The rule claims to map the Bazel execution root, but computes exec_root from ctx.bin_dir.path using split("/bin/"). This is fragile (won’t strip when the string ends with /bin) and does not reliably represent the execution root, so the /pathmap prefix may not match the paths that end up embedded in PDBs.

Other code in this repo that truly needs the execution root obtains it at runtime via bazel info execution_root and handles Windows path formatting explicitly.

• dotnet/private/sourcelink.bzl[29-81]
• dotnet/private/docfx.bzl[35-49]

• Stop using ctx.bin_dir.path.split("/bin/").
• Either:
  • Derive the execroot/workspace root by stripping from the /bazel-out/ segment (as other repo code does), using a robust operation like rsplit/rpartition (and handle both .../bin and .../bin/... cases), or
  • Move execroot detection to execution time (similar to dotnet/private/docfx.bzl using bazel info execution_root) by introducing a small wrapper that expands the correct /pathmap argument before invoking the compiler.

On Windows, the rule still constructs exec_root/pathmap using forward slashes and the POSIX-only split("/bin/"), but the rest of the repo treats Windows tool invocations as requiring backslash paths. This can prevent /pathmap from applying on Windows.

Existing Windows actions convert Bazel-provided paths (which often contain /) into \ before invoking cmd.exe or writing .bat files.

• dotnet/private/sourcelink.bzl[31-43]
• dotnet/private/sourcelink.bzl[78-81]
• dotnet/private/copy_files.bzl[13-31]
• dotnet/private/docfx.bzl[18-24]

• When is_windows is true, build a Windows-normalized pathmap (e.g., convert the computed prefix to \ consistently) or ensure the wrapper uses consistent separator normalization for both the paths being mapped and the /pathmap prefix.

The Read Targets job can succeed while effectively selecting zero test jobs if bazel-targets.txt is missing/unreadable (it falls back to an empty string). Combined with digest-mismatch: warn, this makes it more likely for a corrupted/invalid artifact to allow the workflow to proceed and still report overall success.

Downstream test jobs are guarded by if: needs.read-targets.outputs.<lang> != '', and ci-success only checks for failures/cancellations (skipped jobs do not fail the workflow).

• .github/workflows/ci.yml[68-92]
• .github/workflows/ci.yml[130-141]

Make the Read Targets job fail (or fall back to running a safe default like the full test suite) when bazel-targets.txt is missing/empty/unparseable. Also consider making digest mismatch fatal for the check-targets artifact specifically, since it drives which tests run.

Workflows set digest-mismatch: warn when downloading artifacts via actions/download-artifact@v8, allowing digest mismatches to pass without failing the workflow; in release/publish jobs, this can result in publishing or releasing artifacts even when an integrity mismatch was detected.

The PR updates actions/download-artifact to v8 and explicitly configures digest mismatch handling to warning; per build hardening guidance (PR Compliance ID 14), integrity mismatches should fail deterministically rather than be downgraded. This is particularly important for jobs that publish to PyPI or upload assets to GitHub releases (and other release-like flows), because they use the downloaded artifacts for distribution without any subsequent integrity check.

• .github/workflows/ci-build-index.yml[27-30]
• .github/workflows/ci-rust.yml[238-277]
• .github/workflows/ci-rust.yml[245-248]
• .github/workflows/ci.yml[69-72]
• .github/workflows/commit-changes.yml[49-52]
• .github/workflows/nightly.yml[80-102]
• .github/workflows/nightly.yml[89-93]
• .github/workflows/pin-browsers.yml[35-38]
• .github/workflows/pre-release.yml[260-264]
• .github/workflows/release.yml[160-229]
• .github/workflows/release.yml[171-175]
• .github/workflows/release.yml[198-203]
• .github/workflows/release.yml[206-210]
• .github/workflows/update-documentation.yml[99-103]

py/tox.ini references dependency groups (dependency_groups = lint / validate) that no longer exist because [dependency-groups] was removed from py/pyproject.toml. This breaks tox -e linting and tox -e validate, and also removes the only declarations of ruff and validate-pyproject used by those envs.

• tox uses dependency_groups to install tools like ruff and validate-pyproject.
• This PR deletes the group definitions from py/pyproject.toml, and the new py/requirements.txt does not include those tools either.

1. Re-add [dependency-groups] to py/pyproject.toml with lint and validate entries (include ruff and validate-pyproject, and any other needed pins/ranges).

2. Stop using dependency groups in tox:

   • Update py/tox.ini validate and linting envs to install from -r requirements_lock.txt (or a dedicated dev-tools requirements file).
   • Add ruff and validate-pyproject (and any required companions like packaging if needed) to py/requirements.txt, then regenerate py/requirements_lock.txt.

• py/pyproject.toml[37-56]
• py/tox.ini[8-13]
• py/tox.ini[38-43]
• py/requirements.txt[6-22]

dotnet/private/dotnet_format.bzl changed the invocation from passing user-provided args before the workspace (... format "$@" "$proj") to passing the workspace first (... format "$SOLUTION" "$@"). In this repo, //dotnet:format is invoked with positional commands like style, whitespace, and analyzers (without leading dashes), which are expected to be the first tokens after format.

Existing callers (rake tasks and format scripts) run bazel run //dotnet:format -- style ... and -- whitespace, so the wrapper must preserve the previous ordering where $@ comes before the workspace.

• dotnet/private/dotnet_format.bzl[61-63]
• dotnet/private/dotnet_format.bzl[102-104]

• Unix: change to "$DOTNET" format "$@" "$SOLUTION" (and adjust the echo if desired)
• Windows: change to "%DOTNET%" format %* "%SOLUTION%" (keeping quoting correct)

maven_stable_release fetches maven-metadata.xml via Net::HTTP.get without any timeouts, which can cause rake java:update to hang indefinitely if Maven Central is slow or the connection stalls.

This rake file already uses Net::HTTP.start with explicit open_timeout and read_timeout for other HTTP calls, so timeouts are an established reliability pattern here.

• rake_tasks/java.rake[310-323]
• rake_tasks/java.rake[101-114]

Replace Net::HTTP.get(URI(url)) with a Net::HTTP.start call that sets use_ssl: true plus open_timeout / read_timeout, and read the response body via Net::HTTP::Get so the call fails fast instead of hanging.

javascript/selenium-webdriver/package.json was updated to require multer: ^2.1.1, but the workspace lockfile (pnpm-lock.yaml) still pins javascript/selenium-webdriver to multer 2.0.2. Because Bazel uses npm_translate_lock with pnpm_lock, the dependency upgrade will not be realized (or lock verification may fail due to specifier mismatch).

Bazel’s npm_translate_lock consumes javascript/selenium-webdriver/package.json together with pnpm-lock.yaml. The lockfile must be updated whenever a workspace package.json changes dependency specifiers.

• pnpm-lock.yaml[179-181]
• pnpm-lock.yaml[3005-3008]
• MODULE.bazel[90-104]
• javascript/selenium-webdriver/package.json[35-50]

1. Regenerate/update pnpm-lock.yaml so the importers.javascript/selenium-webdriver.devDependencies.multer specifier matches ^2.1.1 and the resolved version is >=2.1.1.
2. Ensure the packages: section no longer pins only multer@2.0.2 and includes the updated resolved version entry.
3. Re-run the Bazel JS dependency translation step (if part of your workflow) to confirm it succeeds with the updated lock.

scripts/update_py_deps.py builds installed from report.get("install", []) and then uses installed.get(name_normalized); missing entries are treated as unchanged, and if updates stays empty the script prints a success message and exits. This can mask cases where the report is empty/partial and no versions were actually resolved.

This script is used to update pinned versions in py/requirements.txt and is invoked via Bazel (bazel run //scripts:update_py_deps). A silent success with no updates when resolution data is missing makes dependency maintenance unreliable.

• scripts/update_py_deps.py[54-73]

• After parsing the report, validate that every name_normalized from packages exists in installed.
  • If any are missing, raise a RuntimeError that includes a helpful diagnostic (e.g., mention missing names and include result.stderr and a truncated result.stdout).
• Optionally wrap json.loads(result.stdout) in try/except json.JSONDecodeError and raise a clearer error including stderr/stdout context.

scripts/update_py_deps.py parses pip --report - output without validating that the output is valid JSON or that expected keys exist, which can produce unclear crashes (e.g., JSONDecodeError, KeyError).

This script consumes external/protocol-derived data (pip report JSON). Per compliance, failures should be deterministic and actionable (explicit exceptions indicating what was wrong and how to fix).

• scripts/update_py_deps.py[54-56]

• Wrap json.loads(result.stdout) in try/except json.JSONDecodeError and raise a RuntimeError (or custom exception) that includes a short message and relevant stderr/stdout context.
• Validate report is a dict and that report.get("install") is a list.
• When building installed, use .get() accessors (or explicit checks) and raise a descriptive exception if required fields like metadata.name/metadata.version are missing.

py:update now invokes //scripts:update_py_deps, but scripts/update_py_deps.py assumes a POSIX virtualenv layout (venv/bin/pip). On Windows the venv executables live under venv\Scripts\ (e.g., pip.exe), so the script will fail when it tries to run pip.

This regression is introduced by changing py:update from an alias of py:pin to executing //scripts:update_py_deps.

• scripts/update_py_deps.py[34-71]
• rake_tasks/python.rake[127-136]

Update scripts/update_py_deps.py to invoke pip via the venv’s python in a cross-platform way:

• Determine the venv python path with Scripts/python.exe on Windows and bin/python on POSIX, then run python -m pip ....
• Avoid directly calling venv_dir / "bin" / "pip".

Example sketch:

import os
bin_dir = "Scripts" if os.name == "nt" else "bin"
python = venv_dir / bin_dir / ("python.exe" if os.name == "nt" else "python")

subprocess.run([str(python), "-m", "pip", "install", "-q", "--upgrade", "pip"], ...)
subprocess.run([str(python), "-m", "pip", "install", "-q", *install_names], ...)
subprocess.run([str(python), "-m", "pip", "list", "--format=json"], ...)

The PR changes py/requirements.txt to be dev-tooling only, but documentation still instructs installing only that file. This omits selenium runtime dependencies and can break doc generation and local-from-source usage.

py/requirements_lock.txt already contains the full resolved set (including runtime deps coming from py/pyproject.toml). Updating docs to install from the lock file (or otherwise install runtime deps as well) keeps a single workflow aligned with the Bazel lock generation.

• README.md[235-242]
• py/docs/.readthedocs.yaml[10-18]

py/tox.ini currently installs dependencies via -r {toxinidir}/requirements.txt for docs and typecheck, but py/requirements.txt is now dev-tooling only and no longer includes selenium runtime deps (urllib3, websocket-client, typing-extensions, etc.). Since tox runs with PYTHONPATH={toxinidir}/. and Sphinx autodoc/mypy will import selenium modules, these environments will fail with missing-module errors.

The combined pinned set (dev + runtime) is already available in py/requirements_lock.txt (generated from both pyproject.toml and requirements.txt via //py:requirements.update).

• py/tox.ini[15-36]

The PR removes the implicit rust:update invocation from rust:version. At least one existing caller (release_updates) invokes rust:version but does not invoke rust:update, so rust/Cargo.lock will no longer be regenerated/synced as part of that flow.

• rust:update is explicitly described/implemented as regenerating rust/Cargo.lock.
• rust/Cargo.lock contains a selenium-manager package entry with an explicit version.
• release_updates calls rust:version but does not call rust:update.

• Rakefile[104-125]
• rake_tasks/rust.rake[26-33]
• rust/Cargo.lock[1858-1861]

• Update release_updates (and any other flows that require a synced Cargo.lock) to explicitly invoke rust:update after rust:version.
• If repeated invocations are expected in the same process, mirror the previous approach by re-enabling the task before invoking it.

Whitelisted actors cause the Get Approval reusable workflow to run zero jobs (notify is skipped; authorize is skipped because it requires notify success). This can make the reusable workflow job conclude as skipped, which downstream workflows treat as not-approved.

• restrict-trunk.yml requires needs.get-approval.result == 'success' to run manage-trunk when restrict: true.
• pre-release.yml (and release flows) call restrict-trunk.yml with restrict: true, so a skipped approval job can prevent trunk restriction and cascade into the rest of the workflow being skipped.

• .github/workflows/get-approval.yml[20-46]
• .github/workflows/restrict-trunk.yml[38-55]
• .github/workflows/pre-release.yml[76-89]

Create an explicit success path for whitelisted actors (e.g., an auto-authorize job without an environment) so the called workflow concludes success when the actor is in the whitelist.

Example structure:

• Keep notify only for non-whitelisted actors.
• Keep authorize (with environment: production) only for non-whitelisted actors.
• Add auto-authorize (no environment) for whitelisted actors.

This ensures exactly one of authorize / auto-authorize runs, and the reusable workflow result is success in both cases.

The auto-unlock job in pre-release only triggers on failures (failure()), not on cancellations, so a cancelled run after trunk is restricted can leave trunk locked.

Trunk restriction is applied early in the workflow; cancellation mid-run is a plausible operational scenario (manual cancel, timeouts, concurrency cancellations), and leaving trunk restricted requires manual intervention.

• .github/workflows/pre-release.yml[339-349]

Adjust the condition to also cover cancellations, e.g.:

• if: (failure() || cancelled()) && needs.restrict-trunk.result == 'success'

If you find job-level cancellation prevents this job from starting in your environment, consider moving unlock into a separate workflow_run cleanup workflow that triggers on completion of the pre-release workflow and unlocks when the conclusion is failure or cancelled and trunk had been restricted.

The prepare job’s “Check if release ruleset is active” step only writes release-in-progress=true in the success path. If the gh api call fails, the step produces no output, and downstream logic treats it as not in progress.

needs.prepare.outputs.release-in-progress gates the nightly release job. An unset output is not equal to 'true', so the nightly release will run even when the ruleset check failed.

• .github/workflows/nightly.yml[52-61]

Update the step to be fail-safe and to always write an explicit output value.

For example:

• Call gh api and check its exit status.
• If the API call fails, emit a warning and set release-in-progress=true (safe default).
• Otherwise set release-in-progress=true|false based on the jq result.

(Any equivalent approach that distinguishes “false” from “error” and always sets the output is fine.)

The workflow’s ruleset existence check uses jq -e --arg n "$name" 'any(.[]; .name == $n)' <<<"$existing", which assumes $existing is a single valid JSON array. When gh api ... --paginate emits multiple JSON documents (one per page), or when the API returns unexpected/error output, this can cause parse/iteration failures or make the check effectively depend on only the last page, potentially missing an existing ruleset and creating a duplicate, disrupting trunk restrict/unrestrict behavior.

This job locks/unlocks trunk during release; failures can block releases or leave trunk in the wrong state. Missing an existing ruleset due to pagination can create duplicate rulesets with the same .name, making subsequent deletion/unlock behavior ambiguous or incomplete.

• .github/workflows/restrict-trunk.yml[61-67]

The workflow lists existing rulesets using gh api "repos/$GH_REPO/rulesets" but does not use --paginate, so it may only read the first page of results.

The create/delete logic relies on the existing JSON to determine whether to POST new rulesets and which IDs to DELETE. If the repository has more rulesets than fit in one API page, some relevant rulesets may be missed.

• .github/workflows/restrict-trunk.yml[62-63]
• .github/workflows/restrict-trunk.yml[77-78]

Harden the ruleset deletion logic so it does not blindly construct and call DELETE .../rulesets/$id from gh api output; instead, it must validate that the name lookup yields a safe, deterministic set of IDs (and handle empty/multiple matches explicitly) to avoid invalid URLs and non-deterministic failures during unlock.

This is release automation: the unlock path (Delete release rulesets) runs when unlock-trunk.yml calls the workflow with restrict: false. Rulesets are created via POST in a loop and can be recreated on reruns, so duplicate names/IDs are possible; if the lookup returns empty output (not found) or multiple newline-separated IDs (duplicates), the current deletion step can fail unpredictably, produce unclear errors, and block trunk unlock. Consider also validating that the glob .github/rulesets/release-*.json matches at least one file before looping, and fail with a clear message if none are found.

• .github/workflows/restrict-trunk.yml[58-64]
• .github/workflows/restrict-trunk.yml[65-73]
• .github/workflows/unlock-trunk.yml[8-16]

The Create release rulesets step uses POST /rulesets for every JSON file every time restriction is enabled. This can create duplicate rulesets on reruns and interacts badly with name-based deletion.

The delete step selects by .name, so duplicates will either break deletion (multi-id) or leave extra rulesets behind.

• .github/workflows/restrict-trunk.yml[58-64]
• .github/workflows/restrict-trunk.yml[65-73]

Choose one:

• Upsert approach: before POST, query existing rulesets by name; if found, PATCH/PUT that ID (or delete then recreate).
• Delete-then-create approach: on restrict, delete any existing matching rulesets by name first, then create exactly one. In all cases, ensure the script handles 0/1/N matches deterministically.

CanDisownData awaits an async stream LINQ query ending in FirstAsync() without providing a CancellationToken or any timeout. If no matching event is produced, the test can hang indefinitely.

Other tests in this repo bound async stream waits using a CancellationTokenSource(TimeSpan...) (e.g., sub.FirstAsync(cts.Token)) or WaitAsync(TimeSpan...) to avoid CI stalls.

• dotnet/test/webdriver/BiDi/Network/NetworkTests.cs[290-304]

Wrap the FirstAsync with a timeout, e.g.:

• create using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
• call await stream.Where(...).Select(...).FirstAsync(cts.Token); (or equivalently use WaitAsync(TimeSpan.FromSeconds(5)) on the returned task/value-task).

DirectForwardingListener keeps pre-handshake buffered WebSocketFrames on upstream onClose so they can be drained during onUpgrade. If the client-side upgrade never happens, those buffered (ref-counted) frames never get released, creating a potential memory/leak-detector issue.

The code already treats buffered frames as ref-counted (it calls frame.release() on other terminal paths like overflow), but the pre-handshake onClose path retains the buffer without any guaranteed later release.

• java/src/org/openqa/selenium/grid/router/ProxyWebsocketsIntoGrid.java[333-353]
• java/src/org/openqa/selenium/grid/router/ProxyWebsocketsIntoGrid.java[295-313]

When the upstream WebSocket closes/errors before the downstream WebSocket upgrade completes, DirectForwardingListener latches closed=true but drops the close details and onUpgrade(Channel) does not react to the terminal state. If the downstream upgrade completes later, the client channel may be published and left open without a close handshake.

• Upstream connection is initiated before the Netty handshake completes, so pre-upgrade upstream terminal events are possible.
• closeClient() only closes the upstream HttpClient, not the downstream Netty channel.

• Record a terminal state for pre-upgrade close/error (e.g., store closeCode/closeReason, or store a CloseWebSocketFrame to be written post-upgrade).
• In onUpgrade(Channel ch), if a terminal state was observed (closed==true), immediately write a close frame (if applicable) and close the channel (or close without sending if protocol requires), instead of publishing the channel for normal forwarding.
• Add a unit test that calls listener.onClose(...) (or onError(...)) before listener.onUpgrade(channel) and asserts the channel is closed and/or a CloseWebSocketFrame is emitted.

• java/src/org/openqa/selenium/grid/router/ProxyWebsocketsIntoGrid.java[241-306]
• java/src/org/openqa/selenium/grid/router/ProxyWebsocketsIntoGrid.java[308-345]
• java/test/org/openqa/selenium/grid/router/DirectForwardingListenerTest.java[1-106]

DirectForwardingListener uses an unbounded Deque<WebSocketFrame> to buffer frames arriving before onUpgrade(Channel) is called. If the downstream upgrade stalls while upstream continues sending, the deque can grow without limit, retaining ref-counted frames and risking memory exhaustion.

• Buffering is correct for ordering, but needs a safety valve.

• Add a hard limit (by frame count and/or total bytes) for pending.
• When the limit is exceeded, choose a deterministic policy: drop newest/oldest with release(), and/or close the downstream channel once available; also log at WARNING with session context.
• Consider a time-based cutoff (e.g., if upgrade hasn’t completed within N seconds, discard pending and mark closed).

• java/src/org/openqa/selenium/grid/router/ProxyWebsocketsIntoGrid.java[220-285]
• java/src/org/openqa/selenium/grid/router/ProxyWebsocketsIntoGrid.java[331-336]

The mypy override intended to ignore generated DevTools modules uses a slash-separated path pattern (selenium/webdriver/common/devtools.*) which does not match Python module names, so ignore_errors will not take effect.

• py/run_mypy.py runs mypy against the selenium package.
• Generated devtools code lives under selenium/webdriver/common/devtools/... and is imported as selenium.webdriver.common.devtools....

Update the override module pattern to dotted form, e.g. selenium.webdriver.common.devtools.* (and optionally also include selenium.webdriver.common.devtools to cover the package __init__.py).

• py/pyproject.toml[139-145]

pin-browsers.yml uses the write-scoped secrets.SELENIUM_CI_TOKEN for actions/checkout, which is broader than necessary for a read-only clone and increases secret exposure.

The same job already provides SELENIUM_CI_TOKEN to peter-evans/create-pull-request, so checkout does not need to be performed with the PAT.

• Change the checkout step to use the default github.token (or omit token: entirely).
• Optionally set persist-credentials: false on checkout to avoid leaving credentials in the local git config.

• .github/workflows/pin-browsers.yml[29-32]

assumeThat(...) is used in ContentEditableTest but is not imported or qualified, causing compilation failures and preventing the intended Chrome-version test gating.

Other tests in this repo use import static org.assertj.core.api.Assumptions.assumeThat; (or qualify the call via Assumptions.assumeThat(...)). This file currently only imports assertThat and JUnit's assumeFalse.

• java/test/org/openqa/selenium/ContentEditableTest.java[20-33]
• java/test/org/openqa/selenium/ContentEditableTest.java[101-106]
• java/test/org/openqa/selenium/ContentEditableTest.java[115-123]

The WebSocket open handler sets this.connected = true even if _closed was already set by close()/_failPending(), allowing isConnected to become true after the connection is logically closed.

close() calls _failPending() immediately (setting _closed=true), but does not remove/guard the constructor open listener. If open fires after close() is initiated, the state becomes inconsistent.

• javascript/selenium-webdriver/bidi/index.js[39-46]
• javascript/selenium-webdriver/bidi/index.js[96-113]
• javascript/selenium-webdriver/bidi/index.js[275-295]

In the open handler, early-return if this._closed is true (and optionally immediately this._ws.close()/terminate()), so connected cannot be re-enabled after closure.

waitForConnection() now rejects on closed/failed connections, which is a user-visible behavioral change that may break downstream code that previously awaited it without handling rejections.

This class is exported from selenium-webdriver/bidi, so changes to promise rejection behavior can be compatibility-impacting.

• javascript/selenium-webdriver/bidi/index.js[134-155]

waitForConnection() uses this._ws.once('close'|'error', ...) to reject when the socket fails before opening. But close() calls this._ws.removeAllListeners('close') before triggering this._ws.close(), which can remove waitForConnection()’s failure handler if a caller closes while another caller is awaiting connection.

This can lead to an indefinitely pending waitForConnection() (and therefore send()) promise during connection setup/cancellation scenarios.

• javascript/selenium-webdriver/bidi/index.js[133-155]
• javascript/selenium-webdriver/bidi/index.js[272-291]

• Avoid removeAllListeners('close') before the socket actually closes. Instead:
  • Remove only the internal close handler(s) you own (store them as named/bound functions so they can be removed explicitly), or
  • Defer removeAllListeners() until inside the once('close', ...) callback (after other listeners like waitForConnection() have had a chance to run).
• Optionally, make _failPending() also reject/resolve a tracked “connect promise” if you introduce one, so close() can reliably unblock waitForConnection() without relying on WS listener ordering.

waitForConnection() uses a single onFailure handler for both 'close' and 'error' before the socket opens, but it always rejects with BiDi connection closed before opening, losing the real connection error detail.

This only affects the pre-open wait path (callers awaiting waitForConnection() / send() while not connected). Including the underlying error message improves diagnosability.

• javascript/selenium-webdriver/bidi/index.js[143-154]

Split the handlers:

• onClose -> reject with the current close message
• onError(err) -> reject with something like BiDi connection error before opening: ${err.message} Also keep the listener cleanup symmetric (remove the other listeners on success/failure).

After _failPending() runs, connected becomes false, and future send() calls can await waitForConnection() forever because there will be no future 'open' event on a closed/failed socket.

_failPending() is triggered on the underlying WebSocket 'close'/'error' events and marks the connection closed. Many BiDi helper classes call bidi.send() directly; if the connection drops and a command is attempted afterward, the call can hang indefinitely.

• javascript/selenium-webdriver/bidi/index.js[91-101]

Add a fast-fail guard in send() (or waitForConnection()):

• If this._closed is true, immediately reject/throw a clear error.
• Also consider checking this._ws.readyState and rejecting when CLOSING/CLOSED.
• Optionally, have waitForConnection() reject on 'close'/'error' if it is waiting for 'open'.

The shared WebSocket message handler swallows protocol/input problems (JSON parse failures or unexpected payload shapes) by returning early, which can cause callers to see unrelated timeouts and makes failures hard to diagnose.

Messages received over the BiDi WebSocket are protocol-derived external inputs. When they are malformed/unexpected, we should surface a deterministic, actionable error (e.g., emit an error event and/or reject impacted pending requests) rather than silently dropping the message.

• javascript/selenium-webdriver/bidi/index.js[45-54]

Index tracks in-flight requests in _pending, but it does not subscribe to the underlying WebSocket 'close' / 'error' events. If the connection drops without an explicit Index.close() call, pending send() promises will only fail after RESPONSE_TIMEOUT, delaying failure propagation.

• close() now correctly rejects _pending when invoked, but unexpected disconnects still leave callers waiting up to 30 seconds.
• Since there is now a single dispatcher and centralized _pending, the most reliable place to fail outstanding requests is in a single socket-level close/error handler.

• javascript/selenium-webdriver/bidi/index.js[33-63]
• javascript/selenium-webdriver/bidi/index.js[217-241]

• Add _ws.on('close', ...) and _ws.on('error', ...) handlers in the constructor.
• In those handlers:
  • set this.connected = false
  • iterate _pending.values() and clearTimeout(timeoutId) then reject(new Error(...))
  • _pending.clear()
• Ensure handlers are idempotent (e.g., guard with a boolean like this._closed = true) so close() and 'close' event don’t double-reject.
• (Optional) extend tests to simulate server-side disconnect and assert pending sends reject promptly (without waiting for the timeout).

publish-python sets permissions to only id-token: write, which overrides the workflow defaults and leaves the job’s GITHUB_TOKEN without the scopes that actions/download-artifact@v4 may require to fetch artifacts. This can break Python publishing because the pypi-distributions artifact may not download.

This workflow already uses a broader permission set in other jobs that perform authenticated GitHub API operations (including artifact downloads).

• .github/workflows/release.yml[96-110]

Update publish-python permissions to include the minimal required scopes for artifact download, e.g.:

permissions:
  id-token: write
  contents: read
  actions: read

(Keep id-token: write for PyPI trusted publishing.)