-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Enterprise Search] Fix bug in Add Schema modal #104024
[Enterprise Search] Fix bug in Add Schema modal #104024
Conversation
This PR fixes a bug where an error passed from the server was not rendering and was causing the UI to hang. The problem is that the `body` property was missed in the error object.
@@ -31,12 +31,13 @@ interface Options { | |||
isQueued?: boolean; | |||
} | |||
|
|||
// TODO I know our error messages from the BE are not i18n-ized but should this be? |
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.
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.
Currently none of our error messages from the BE are localized, but if this one is in public/
it has access to i18n
, so we should likely i18n it just in case.
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.
Also want to add it wouldn't be my preference to export this const. I'd just check for the static 'An unexpected error occurred'
string in the schema logic file. It's short, easy to read, and gives developers human-readable context over a variable that means nothing if they don't open another file to check it
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.
Oh wait, sorry, just saw we're using it in the actual logic file, not just the test. Hm, sec
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.
I'll i18n this
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.
This looks great, thanks, Byron and Scotty! 🙌
P.S: really liked that we also verify scrollTo(0,0)
behavior!
if (isAdding) { | ||
actions.onSchemaSetFormErrors(e?.message); | ||
// We expect body.message to be a string[] for actions.onSchemaSetFormErrors | ||
const message: string[] = e?.body?.message || [defaultErrorMessage]; | ||
actions.onSchemaSetFormErrors(message); | ||
} else { | ||
flashAPIErrors(e); | ||
} |
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.
Why not just add the e?.body?.message
check into the conditional and let invalid error formats fall back to flashAPIErrors
, instead having to manually fall back to defaultErrorMessage
?
if (isAdding) { | |
actions.onSchemaSetFormErrors(e?.message); | |
// We expect body.message to be a string[] for actions.onSchemaSetFormErrors | |
const message: string[] = e?.body?.message || [defaultErrorMessage]; | |
actions.onSchemaSetFormErrors(message); | |
} else { | |
flashAPIErrors(e); | |
} | |
const errorMessage: string[] = e?.body?.message; | |
if (isAdding && errorMessage) { | |
actions.onSchemaSetFormErrors(errorMessage); | |
} else { | |
flashAPIErrors(e); | |
} |
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.
I think this would be a slight functional difference, in that when the message is missing, it would appear as a Flash Message error. actions.onSchemaSetFormErrors sets addFormFieldErrors which is used inside a SchemaAddFieldModal. I think we'd still want the default error message to appear in the SchemaAddFieldModal.
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.
I don't have a strong opinion either way. I guess I'm leaning slightly towards showing the error in the modal, closer to the user action that lead to the error. But I see the point in showing it as a flash message: if the error is unexpected, it's probably not caused by user action.
I will merge the PR as-is because the code fixes the original bug and is already tested.
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
* [Enterprise Search] Fix bug in Add Schema modal This PR fixes a bug where an error passed from the server was not rendering and was causing the UI to hang. The problem is that the `body` property was missed in the error object. * Use default message when error response for actions.setServerField has no message * i18n-ize default error message * Remove TODO Co-authored-by: Byron Hulcher <byronhulcher@gmail.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
* [Enterprise Search] Fix bug in Add Schema modal This PR fixes a bug where an error passed from the server was not rendering and was causing the UI to hang. The problem is that the `body` property was missed in the error object. * Use default message when error response for actions.setServerField has no message * i18n-ize default error message * Remove TODO Co-authored-by: Byron Hulcher <byronhulcher@gmail.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Scotty Bollinger <scotty.bollinger@elastic.co> Co-authored-by: Byron Hulcher <byronhulcher@gmail.com>
In elastic#104024, the error handling incorrectly used the `message` property on the response, when it should have been the attributes.errors array.
…ing state (elastic#104360) * Fix an issue from previous PR In elastic#104024, the error handling incorrectly used the `message` property on the response, when it should have been the attributes.errors array. * Use inline error for duplicate name
…ing state (elastic#104360) * Fix an issue from previous PR In elastic#104024, the error handling incorrectly used the `message` property on the response, when it should have been the attributes.errors array. * Use inline error for duplicate name
…ing state (#104360) (#104636) * Fix an issue from previous PR In #104024, the error handling incorrectly used the `message` property on the response, when it should have been the attributes.errors array. * Use inline error for duplicate name Co-authored-by: Scotty Bollinger <scotty.bollinger@elastic.co>
* [Enterprise Search] Fix bug in Add Schema modal This PR fixes a bug where an error passed from the server was not rendering and was causing the UI to hang. The problem is that the `body` property was missed in the error object. * Use default message when error response for actions.setServerField has no message * i18n-ize default error message * Remove TODO Co-authored-by: Byron Hulcher <byronhulcher@gmail.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
…ing state (elastic#104360) * Fix an issue from previous PR In elastic#104024, the error handling incorrectly used the `message` property on the response, when it should have been the attributes.errors array. * Use inline error for duplicate name
) * [Enterprise Search] Fix bug in Add Schema modal (#104024) * [Enterprise Search] Fix bug in Add Schema modal This PR fixes a bug where an error passed from the server was not rendering and was causing the UI to hang. The problem is that the `body` property was missed in the error object. * Use default message when error response for actions.setServerField has no message * i18n-ize default error message * Remove TODO Co-authored-by: Byron Hulcher <byronhulcher@gmail.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> * [Workplace Search] Fix bug where error was behind modal stuck in loading state (#104360) * Fix an issue from previous PR In #104024, the error handling incorrectly used the `message` property on the response, when it should have been the attributes.errors array. * Use inline error for duplicate name Co-authored-by: Scotty Bollinger <scotty.bollinger@elastic.co> Co-authored-by: Byron Hulcher <byronhulcher@gmail.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
This PR fixes a bug where an error passed from the server was not rendering and was causing the UI to hang. The problem is that the
body
property was missed in the error object.closes https://github.com/elastic/workplace-search-team/issues/1784