• Merges default parameters into RestRequest early in ExecuteRequestAsync
• Makes default headers visible in RestResponse.Request.Parameters collection
• Removes redundant default parameter merges from multiple components
• Adds integration test verifying default headers appear in response

Merge default parameters early in request execution

• Merges default parameters into request.Parameters early in ExecuteRequestAsync before request
 building
• Checks for duplicate parameters by name and type to avoid duplication on request reuse
• Removes redundant AddHeaders call for DefaultParameters in RequestHeaders initialization

src/RestSharp/RestClient.Async.cs

Remove redundant default parameter merge

• Simplifies _parameters initialization to use only request.Parameters instead of union with
 DefaultParameters
• Removes redundant parameter merging since defaults are now merged earlier

src/RestSharp/Request/RequestContent.cs

Remove redundant default parameter handling

• Removes DefaultParameters from BuildUriWithoutQueryParameters method
• Removes DefaultParameters from GetRequestQuery method
• Simplifies parameter collection to use only request.Parameters

src/RestSharp/BuildUriExtensions.cs

Description

The new default-parameter merge deduplicates by Name+Type, which drops additional default
headers/parameters that intentionally share the same name (e.g., multiple header values). This can
cause missing default headers in RestResponse.Request.Parameters and potentially alters the
headers actually sent.

Code

src/RestSharp/RestClient.Async.cs[R105-109]

+        foreach (var defaultParam in DefaultParameters) {
+            if (!request.Parameters.Any(p => p.Name == defaultParam.Name && p.Type == defaultParam.Type)) {
+                request.Parameters.AddParameter(defaultParam);
+            }
+        }

Evidence

Compliance requires default headers added via AddDefaultHeader to appear in
RestResponse.Request.Parameters. The new merge logic skips adding any default parameter once one
with the same Name+Type exists, which prevents multiple default headers with the same name from
being represented (even though default headers are allowed to have multiple values).

Include RestClient default headers in RestResponse.Request.Parameters
src/RestSharp/RestClient.Async.cs[104-109]
src/RestSharp/Options/RestClientOptions.cs[218-222]
src/RestSharp/Parameters/DefaultParameters.cs[29-38]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The merge of `DefaultParameters` into `request.Parameters` currently deduplicates purely by `Name` + `Type`, which drops additional default headers/parameters that intentionally share a name (e.g., multiple `HttpHeader` values). This can prevent all configured default headers from appearing in `response.Request.Parameters` and can change what is actually sent.
## Issue Context
`RestClientOptions.AllowMultipleDefaultParametersWithSameName` explicitly does not apply to headers (multiple values are allowed), and `DefaultParameters.AddParameter` also allows duplicates for `HttpHeader` and certain multi-parameter types. The merge should respect those semantics.
## Fix Focus Areas
- src/RestSharp/RestClient.Async.cs[104-109]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

BuildUriWithoutQueryParameters and GetRequestQuery no longer include client.DefaultParameters,
so client.BuildUri* omits default URL segments and query parameters unless the request was
previously executed/mutated. This is a behavioral regression for a public API that’s expected to
reflect defaults used “on every request.”

Code

src/RestSharp/BuildUriExtensions.cs[R53-58]

           var (uri, resource) = client.Options.BaseUrl.GetUrlSegmentParamsValues(
               request.Resource,
               client.Options.Encode,
-                request.Parameters,
-                client.DefaultParameters
+                request.Parameters
           );
           return uri.MergeBaseUrlAndResource(resource);

Evidence

BuildUriString delegates to BuildUriWithoutQueryParameters and GetRequestQuery, both of which
now only look at request.Parameters. Meanwhile, DefaultParameters are defined as client-level
defaults used on every request, and the URL-segment replacement helper supports multiple parameter
collections (which previously enabled passing both request and defaults).

src/RestSharp/BuildUriExtensions.cs[35-43]
src/RestSharp/BuildUriExtensions.cs[50-58]
src/RestSharp/BuildUriExtensions.cs[66-70]
src/RestSharp/IRestClient.cs[31-35]
src/RestSharp/Request/UriExtensions.cs[50-66]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`BuildUri*` no longer considers `client.DefaultParameters`, so URLs built via `client.BuildUri()` / `BuildUriString()` can omit default query params and URL segments.
### Issue Context
These methods are public API and are commonly used to inspect/preview the final request URI.
### Fix Focus Areas
- src/RestSharp/BuildUriExtensions.cs[50-58]
- src/RestSharp/BuildUriExtensions.cs[66-70]
- src/RestSharp/Request/UriExtensions.cs[50-66]
- src/RestSharp/IRestClient.cs[31-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

OAuth1 signing no longer includes client.DefaultParameters when OAuth1Authenticator.Authenticate
(or AddOAuthData) is called directly, producing incorrect signatures when defaults contain
query/post params. This is a realistic scenario since tests call Authenticate directly (outside
ExecuteRequestAsync).

Code

src/RestSharp/Authenticators/OAuth/OAuth1Authenticator.cs[R258-262]

               ? x => BaseQuery(x) && x.Name != null && x.Name.StartsWith("oauth_")
               : (Func<Parameter, bool>)BaseQuery;

-        parameters.AddRange(client.DefaultParameters.Where(query).ToWebParameters());
       parameters.AddRange(request.Parameters.Where(query).ToWebParameters());

Evidence

AddOAuthData now only uses request.Parameters to build the OAuth signature parameter set. In the
normal RestClient.ExecuteRequestAsync path, defaults are merged before calling Authenticate, but
when Authenticate is invoked directly, that merge never runs; the test suite demonstrates direct
Authenticate usage, implying it’s supported/expected.

src/RestSharp/Authenticators/OAuth/OAuth1Authenticator.cs[256-262]
src/RestSharp/RestClient.Async.cs[104-117]
test/RestSharp.Tests/Auth/OAuth1Tests.cs[43-50]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
OAuth1 signature generation no longer considers `client.DefaultParameters` when the authenticator is used directly, which can generate incorrect signatures for clients configured with default query/post parameters.
### Issue Context
The library test suite calls `authenticator.Authenticate(client, request)` directly, so direct usage is part of supported workflows.
### Fix Focus Areas
- src/RestSharp/Authenticators/OAuth/OAuth1Authenticator.cs[256-262]
- src/RestSharp/RestClient.Async.cs[104-117]
- test/RestSharp.Tests/Auth/OAuth1Tests.cs[43-50]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

ExecuteRequestAsync permanently mutates the caller-provided RestRequest by adding default
parameters, which can make request reuse produce stale/incorrect defaults and can leak one client’s
defaults into subsequent executions. This also makes behavior depend on whether the request has been
executed before.

Code

src/RestSharp/RestClient.Async.cs[R104-109]

+        // Merge default parameters into the request so they are visible in response.Request.Parameters
+        foreach (var defaultParam in DefaultParameters) {
+            if (!request.Parameters.Any(p => p.Name == defaultParam.Name && p.Type == defaultParam.Type)) {
+                request.Parameters.AddParameter(defaultParam);
+            }
+        }

Evidence

The merge writes directly into the RestRequest.Parameters collection, and the response holds a
reference to the same RestRequest instance; therefore, the mutation persists beyond execution.
RestRequest.Parameters is a long-lived property on the request object, so subsequent uses of the
same request will include the previously merged defaults (and the merge’s de-dupe logic will prevent
updated defaults from being applied).

src/RestSharp/RestClient.Async.cs[104-109]
src/RestSharp/Request/RestRequest.cs[106-112]
src/RestSharp/Response/RestResponseBase.cs[29-33]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ExecuteRequestAsync` currently mutates the caller-provided `RestRequest` by injecting defaults, which can cause surprising/stale behavior when the same `RestRequest` instance is reused.
### Issue Context
`RestResponse` stores the same `RestRequest` instance reference, so any mutation during execution becomes observable and persistent.
### Fix Focus Areas
- src/RestSharp/RestClient.Async.cs[104-109]
- src/RestSharp/Request/RestRequest.cs[106-112]
- src/RestSharp/Response/RestResponseBase.cs[29-33]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools