fix(pollers/util.go): Handle missing JSON path gracefully by using entire payload

[yyoshiki41]

What

ResultHelper attempts to extract the value at the specified JSON path.
If the specified JSON path is not found in the response, the entire payload is used as the result.

Why

In #22980, JSON path extraction was introduced.
However, in Azure Document Intelligence that adopted Operation-Location header strategy, it is not included under the key payloadPath: "result". As a result, the correct output cannot be retrieved (always nil).

This fix updates the logic to use the entire response if the specified JSON path key does not exist.

Ref

• Azure Document Intelligence quickstart guide.

---

• The purpose of this PR is explained in this or a referenced issue.
• The PR does not update generated files.
  • These files are managed by the codegen framework at Azure/autorest.go.
• Tests are included and/or updated for code changes.
• Updates to module CHANGELOG.md are included.
• MIT license headers are included in each file.

[github-actions]

Thank you for your contribution @yyoshiki41! We will review the pull request and get back to you soon.

[yyoshiki41]

@microsoft-github-policy-service agree

[jhendrixMSFT]

@JeffreyRichter shouldn't the payload for the terminal success case always be under the result property in the status monitor JSON response? I thought that was the contract.

[yyoshiki41]

Reproduction Steps

After upgrading to github.com/Azure/azure-sdk-for-go/sdk/[email protected], result is always nil when executing the following pseudo code.

{
	endpoint := "endpoint"
	req, err := runtime.NewRequest(ctx, http.MethodPost, endpoint)
	if err != nil {
		return nil, err
	}
	if err := req.SetBody(&readSeekCloser{bytes.NewReader(body)}, "application/json"); err != nil {
		return nil, err
	}
	// Start pipeline
	pipeline := c.azure.Pipeline()
	resp, err := pipeline.Do(req)
	if err != nil {
		return nil, err
	}
	defer resp.Body.Close()

	if resp.StatusCode >= 400 {
		return nil, runtime.NewResponseError(resp)
	}

	// Poll until the operation is done
	options := &runtime.NewPollerOptions[AnalyzeResponse]{}
	poller, err := runtime.NewPoller(resp, pipeline, options)
	if err != nil {
		return nil, err
	}
	result, err := poller.PollUntilDone(ctx, &runtime.PollUntilDoneOptions{})
}

// AnalyzeResponse represents a response from the Analyze operation
type AnalyzeResponse struct {
	Status              string        `json:"status"`
	CreatedDateTime     time.Time     `json:"createdDateTime"`
	LastUpdatedDateTime time.Time     `json:"lastUpdatedDateTime"`
	AnalyzeResult       AnalyzeResult `json:"analyzeResult"`
}

[JeffreyRichter]

The guidelines are here: https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#long-running-operations--jobs

We have 4 LRO patterns: PUT, DELETE, LRO Action on resource & LRO action not on a resource. Just the LRO action patterns have a result property and yes, this property should only be set/read when the status is "success".

[yyoshiki41]

@JeffreyRichter @jhendrixMSFT

Just the LRO action patterns have a result property and yes, this property should only be set/read when the status is "success".

I understand that only the LRO action patterns have a result property, which should only be set or read when the status is “success.”
Does this mean that Azure Document Intelligence doesn’t fall under these LRO action patterns, and therefore, the result property wouldn’t apply in this case? If so, should we avoid using runtime.NewPoller in Document Indelligence?

	poller, err := runtime.NewPoller(resp, pipeline, options)

Thanks.

[yyoshiki41]

@JeffreyRichter @jhendrixMSFT

I wanted to kindly follow up on this pull request as it’s been pending for about a month now.
Could you please let me know if there’s anything further I can address to help move this forward?
I’d be happy to make any adjustments as needed to expedite the review process.

Thanks!

[jhendrixMSFT]

Sorry for the delay, I'm looking into this some more.

[jhendrixMSFT]

We had an internal discussion, and the conclusion is that the result path must be configurable instead of hard coded to "result". I've opened #23733 to address this which should also fix your scenario.