[core-lro] Support path rewriting

[deyaaeldeen]

Packages impacted by this PR

@azure/core-lro

Issues associated with this PR

Addresses #33321

Describe the problem that is addressed by this PR

LRO operations return specific URLs in the initial response that should be used to polling the operation and to also retrieve the resource being created, if any. These URLs are currently being treated opaquely, however, if the LRO operation lives behind some API gateway, the polling and resource location URLs won't be updated to point to the gateway instead.

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?

I am adding a baseUrl option where the caller can specify if they want to rewrite the these URLs to use this base URL. I think this approach strikes a good balance between complexity and keeping the user in control. Alternatively, there are a few ideas I considered:

• Automatic detection of path rewriting need: add smarter logic to detect if the URLs are pointing to the same host as the original request and rewrite them accordingly. However, I am worried this could break customers who may want to keep polling from the original URLs.
• URL rewriting callback: add an optional user-defined callback that we pass the URLs through first, however, this is overkill in most cases. This could be useful if the service is returning incomplete polling URLs for some reason and the user may want to append additional query parameters. The user can still do this if they update their RunningOperation.sendPollRequest to handle such customization.
• None: do nothing and let sendPollRequest handle the path rewriting, however, if we want to support this scenario across our libraries, the rewriting logic will need to be centralized somewhere else and the libraries will have to import from two different places.

Are there test cases added in this PR? (If not, why?)

Yes!

Provide a list of related PRs (if any)

N/A

Checklists

• Added impacted package name to the issue description
• Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
• Added a changelog (if necessary)

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

@azure/core-lro

[Copilot]

Pull Request Overview

This PR adds support for URL rewriting for long-running operations by introducing a baseUrl option. Key changes include:

• Introducing the rewriteUrl utility to handle URL rewriting.
• Updating the testing suite to validate rewritten polling and resource URLs.
• Adding a baseUrl option to the poller and LRO API configuration.

Reviewed Changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
sdk/core/core-lro/src/http/utils.ts	Implements and exports the core URL rewriting functionality.
sdk/core/core-lro/test/lro.spec.ts	Adds tests to verify that polling URLs are rewritten when a baseUrl is provided.
sdk/core/core-lro/CHANGELOG.md	Updates changelog to reflect the new feature.
sdk/core/core-lro/test/utils/router.ts	Updates type definitions and refactors test poller utility functions.
sdk/core/core-lro/src/http/models.ts	Adds the baseUrl field to the CreateHttpPollerOptions interface.
sdk/core/core-lro/review/core-lro.api.md	Updates the API definition to include the baseUrl option.
sdk/core/core-lro/src/http/poller.ts	Integrates URL rewriting into the poller creation logic.
sdk/core/core-lro/test/utils/utils.ts	Updates type annotations for operation state in tests.
sdk/core/core-lro/src/http/operation.ts	Adds explicit type annotation to the nested getDefault function.

Comments suppressed due to low confidence (1)

sdk/core/core-lro/test/lro.spec.ts:2956

• Consider adding additional test cases to cover scenarios where the input URL is relative to ensure that rewriteUrl correctly handles both absolute and relative URL inputs.

it("polling URL is rewritten if the baseUrl option is provided ", async function () {

[jeremymeng]

Looks good! If really needed in the future, we could still expand it to take a string or a callback returning string, without breaking customers.

[xirzec]

Small remarks, thanks for enhancement!