You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Repository collaborators can run the JMH benchmark suite against this PR by commenting:
/benchmark
Optional regression threshold override (Δ% on Time or Alloc/op; defaults to 10%):
/benchmark threshold=15
Only one benchmark run per PR is active at a time — issuing a new /benchmark comment cancels the previous run. After the run finishes a separate comment will be posted comparing it against the latest scheduled run on main; the PR check fails if any benchmark regresses by more than the threshold.
Summary
This PR consolidates the multipart-vs-plain request dispatch logic from Client.java into HttpAPIClientHelper.executeRequest(), eliminating the separate executeMultiPartRequest() method. Previously, Client.java checked HTTP_SEND_PARAMS_IN_BODY and whether queryParams != null to decide which transport method to call. Now executeRequest reads those settings itself and branches internally. The stated motivation is abstracting the transport layer so Client no longer needs to know how parameters are physically sent. No new capability is added; no issue is linked.
The multipart dispatch condition has subtly changed: queryParams != null (checked at call site) is replaced by requestConfig.containsKey(KEY_STATEMENT_PARAMS) (checked inside the transport). These are not guaranteed to be equivalent; if a caller populates requestConfig differently than it sets queryParams, behavior may diverge silently.
executeMultiPartRequest is removed — was public on an internal class, but any reflection-based callers or future subclasses break.
Concerns
Behavioral change in client-v2 hot path (Medium rule): the guard condition for multipart mode changed (queryParams != null → containsKey(KEY_STATEMENT_PARAMS)), which is a semantically different check that is untested by this PR.
No tests added: the PR checklist leaves the test line unchecked; there is no regression test covering multipart vs. plain path selection.
No linked issue: a non-trivial behavioral refactor in a hot-path transport method with no issue reference makes intent and rollback scope unclear (intent drift concern).
Required reviewer action
At least one human reviewer should verify that the new condition requestConfig.containsKey(KEY_STATEMENT_PARAMS) is strictly equivalent to the old queryParams != null guard, and request a targeted integration test covering both code paths.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
We need to abstract transport layer. However logic that selects how to send query parameters are in Client still.
This PR fixes it.
Checklist
Delete items not relevant to your PR: