The api-version parameter to start a job should be passed back in the Operation-Location header

[heaths]

While working on the authoring client, we found that long-running operations (LROs) were 404'ing during status updates because the api-version query parameter was not returned. Talking with @JeffreyRichter, the Operation-Location for LROs (and nextLink for paged results) should be opaque, so they need to include the api-version parameter - the same one passed during the request to start a job or get paged results.

@ChongTang could you also check if CLU might have this problem?

I'll also be opening bugs that generated code should add it if missing based on the client options, but ideally services do this consistently so any caller doesn't have to work around the issue.

/cc @annatisch @AhmedLeithy @ZulaMostafa @mshaban-msft

[heaths]

While it doesn't necessarily help in this situation, @johanste also says that the service shouldn't 404, but 400 (bad parameter) if api-version is required and not specified.

[rokulka]

I'll be looking into it for QuestionAnswering, planning a rollout of the fix by 12/3.

The 404 vs 400 if api-version is not specified caused by the APIM, I will sync with the APIM team for that.