[QUERY] lambda in RequestContext

[weidongxu-microsoft]

Query/Question
RequestContext is composed of a sequence of Consumer<HttpRequest> requestCallback.

On "Paging: Query parameter re-injection (emitter work)" task, generated SDK is required to find e.g. a value of query queryParam on 1st HTTP GET page, and set the query parameter with that value in all subsequent paging calls.
(also, see test case Azure/typespec-azure#2497)

E.g., user start the paging with

GET /endpoint/page?query=value1

backend returns the values, with a {nextLinkUrl} without query, and SDK would need to continue with

GET {nextLinkUrl}&query=value1

Now, with all these Consumer<HttpRequest> requestCallback, it is very hard for SDK code to figure out which query parameter be set, and which value it sets, in 1st HTTP GET done by user.

Why is this not a Bug or a feature Request?
There may exists some workaround, e.g. add a last requestCallback to parse the URL and extract the query and value.

But apparently this is very tricky (the order of requestCallback matters) and hard to read (exact to an Atomic or mutable Map and write back in 2nd call?).

Setup (please complete the following information if applicable):

• OS: [e.g. iOS]
• IDE: [e.g. IntelliJ]
• Library/Libraries: io.clientcore:core:1.0.0-beta.8

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Query Added
• Setup information Added

[alzimmermsft]

Thanks for bringing this up @weidongxu-microsoft!

Slight aside, but related, I've also been pondering how URL manipulation could be made better in RequestOptions / RequestContext as multiple query parameter mutations require multiple parses of the URL which are redundant. I'm wondering if RequestContext would be better off maintaining a UrlBuilder / UriBuilder (azure-core vs ClientCore context) where we provide:

RequestContext modifyUri(UriBuilder)

which offers a mutable UriBuilder that maintains the modifications made previous and also allows for introspection on existing information. Ex, check for query parameter foo existing before setting it, if it exists override or append based on what's needed for that API call.

FYI @JonathanGiles @srnagar