-
Notifications
You must be signed in to change notification settings - Fork 906
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
Conversation
…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>
❌ Empty Changelog SectionThe 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. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@@ -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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
queryStatusResponse
could be undefined.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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> => { |
OpenSearch-Dashboards/src/plugins/query_enhancements/server/types.ts
Lines 48 to 51 in 8d847a5
export interface FacetResponse { | |
success: boolean; | |
data: any; | |
} |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
Dismissing to unblock release but a followup is warranted.
Description
Backport PR:
#8771
From 8771:
Changelog
Check List
yarn test:jest
yarn test:jest_integration