Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.x-manual-bp][Discover] Fix error handling for ppl jobs API (#8771) #8777

Merged
merged 1 commit into from
Oct 31, 2024

Conversation

ananzh
Copy link
Member

@ananzh ananzh commented Oct 31, 2024

Description

Backport PR:
#8771

From 8771:

  • fix error handling for ppl jobs API

Changelog

Check List

  • All tests pass
    • yarn test:jest
    • yarn test:jest_integration
  • New functionality includes testing.
  • New functionality has been documented.
  • Update CHANGELOG.md
  • Commits are signed per the DCO using --signoff

…arch-project#8771)

Backport PR:
opensearch-project#8771

From 8771:
* fix error handling for ppl jobs API

Signed-off-by: Shenoy Pratik <[email protected]>

* Changeset file for PR opensearch-project#8771 created/updated

---------

Signed-off-by: Shenoy Pratik <[email protected]>
Co-authored-by: opensearch-changeset-bot[bot] <154024398+opensearch-changeset-bot[bot]@users.noreply.github.com>
Copy link
Contributor

❌ Empty Changelog Section

The Changelog section in your PR description is empty. Please add a valid changelog entry or entries. If you did add a changelog entry, check to make sure that it was not accidentally included inside the comment block in the Changelog section.

Copy link

codecov bot commented Oct 31, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 51.73%. Comparing base (1cc5c0f) to head (8d847a5).
Report is 1 commits behind head on 2.x.

❗ There is a different number of reports uploaded between BASE (1cc5c0f) and HEAD (8d847a5). Click for more details.

HEAD has 2 uploads less than BASE
Flag BASE (1cc5c0f) HEAD (8d847a5)
Linux_4 1 0
Windows_2 1 0
Additional details and impacted files
@@            Coverage Diff             @@
##              2.x    #8777      +/-   ##
==========================================
- Coverage   60.81%   51.73%   -9.09%     
==========================================
  Files        3797     3513     -284     
  Lines       90711    86798    -3913     
  Branches    14274    13655     -619     
==========================================
- Hits        55169    44905   -10264     
- Misses      32091    38812    +6721     
+ Partials     3451     3081     -370     
Flag Coverage Δ
Linux_1 29.06% <ø> (ø)
Linux_4 ?
Windows_1 29.07% <ø> (ø)
Windows_2 ?
Windows_3 37.64% <ø> (ø)
Windows_4 29.94% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -59,6 +59,9 @@ export const pplAsyncSearchStrategyProvider = (
} else {
request.params = { queryId: inProgressQueryId };
const queryStatusResponse: any = await pplAsyncJobsFacet.describeQuery(context, request);

if (!queryStatusResponse.success) handleFacetError(queryStatusResponse);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

queryStatusResponse could be undefined.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this describeQuery calls fetchJobs or fetch. Both wraps the API call in a try-catch block: If the API call succeeds, it returns { success: true, data: queryRes }. If the API call fails, it returns { success: false, data: err }. So the result is either return { ...response, data: shimFunctionsdataType } or response, with success either true or false right?

So the result from describeQuery could be

 if (response.success === false || !this.shimResponse) return response;

where it has success either true or false.

or

shimFunctions[dataType]
      ? { ...response, data: shimFunctions[dataType](response.data) }
      : response;

where it still has response in both ways. So seems the exception for describeQuery can be captured in facet error right? What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it won't be undefined:

public describeQuery = async (context: any, request: any): Promise<FacetResponse> => {

export interface FacetResponse {
success: boolean;
data: any;
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue i am having is queryStatusResponse: any. Will need to understand why the code doesn't use queryStatusResponse: FacetResponse and why the nest line does queryStatusResponse?.data.

Copy link
Member

@joshuali925 joshuali925 Oct 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes i don't know why it uses any, type can be omitted since for describeQuery, the return type is correct and there are no type errors in it

data shouldn't be any as well, it should be either Error or the response type.

And i think the real problem is that i'm not sure why it goes from

error response -> catch -> return with `success: false` -> check if `success === false` -> throw new error wrapping response error

instead of just

error response -> throw response error

in the current logic it's likely to miss checking success === false. This PR and my PR #8743 were fixing the same problem that this check is missing

@AMoo-Miki AMoo-Miki self-requested a review October 31, 2024 20:14
@AMoo-Miki AMoo-Miki dismissed their stale review October 31, 2024 20:17

Dismissing to unblock release but a followup is warranted.

@ananzh ananzh merged commit 5434201 into opensearch-project:2.x Oct 31, 2024
66 of 68 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants