Are we saying that if I PUT MyResource on version 2, then the polling url will get a api-version querystring of 2?
Or are we saying that if the client has a definition for the operationResult at v=1 then that's the version to use for polling that resource no matter what?

example:

ManagedCluster resource has api-version 2023-08-01
OperationResult resource has api-version 2020-01-01 - it has been stable for a long time.

ManagedCluster response returns an OperationResult url in the header.

Should the SDK detect that this is an operationResult resource and the api-version it knows about for it (i.e: 2020-01-01)?
Should the SDK expect the OperationResult to support 2023-08-01, and use this version for polling, because the ManagedCluster was created at this version?
Should the polling just be dumb, and poll what it's given? (Opaque url)

Is a reasonable behavior, but unnecessarily strict IMO. What if I give you a polling url that is not part of the Client? The poller is currently not unmarshalling to a concrete type anyways, it relies on http status code and provisioning status value.
I think this is wrong, it breaks the point of versioning per resource type, so assuming you're going for 1.
This is what happens today, why is it a problem? are you trying to reduce the switch case of the poller decision making?

IMO this would be a fine compromise that does not require a boolean:

if the server gives you an api-version, you should use that (3.) - preferred but should be documented in the guideline.
if it doesn't, you should do (1.) - use the version known by the client.

Overriding the value explicitely sent by the service can only lead to some unexpected behavior and issues for the service team.

If you expect the polling URL to be a resource that the client knows about, then why are we sending the URL, and not a resourceID?

Pagers/Pollers must use a client's api-version #21408

Description

jhendrixMSFTopenedon Aug 21, 2023

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

jhendrixMSFT
openedon Aug 21, 2023