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

[APM] Surface http errors to users #42160

Merged
merged 4 commits into from
Jul 31, 2019

Conversation

sorenlouv
Copy link
Member

@sorenlouv sorenlouv commented Jul 29, 2019

Closes #40986

For components that don't handle errors explicitly a generic toast error will be displayed
Screen Shot 2019-07-29 at 17 33 03

The only component that handle errors explicitly is the service overview (this being the first page the users see, it's probably a bit more important)
Screen Shot 2019-07-29 at 16 27 20

@sorenlouv sorenlouv requested a review from a team as a code owner July 29, 2019 15:44
@elasticmachine
Copy link
Contributor

💔 Build Failed

@sorenlouv sorenlouv added release_note:enhancement Team:APM All issues that need APM UI Team support labels Jul 29, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/apm-ui

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@sorenlouv sorenlouv force-pushed the display-fetch-errors branch from 8724579 to 3a3948f Compare July 30, 2019 09:43
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@sorenlouv sorenlouv requested review from ogupte and dgieselaar July 30, 2019 15:02
Copy link
Member

@dgieselaar dgieselaar left a comment

Choose a reason for hiding this comment

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

LGTM, just a few nits.

<NoServicesMessage isLoading={false} historicalDataFound={false} />
);
expect(wrapper).toMatchSnapshot();
Object.values(FETCH_STATUS).forEach(status => {
Copy link
Member

Choose a reason for hiding this comment

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

are these useful tests? I guess they don't hurt either, but it feels like it's just generating code paths and then generating snapshots of all the different code paths. The component itself seems to be simple (and will likely stay that way) to warrant snapshot tests.

Copy link
Member Author

Choose a reason for hiding this comment

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

I felt it was an okay-ish way to test the different code paths since the generated snapshots were rather small (I agree that changes in big snapshots are often overlooked). What do you suggest instead?

title: i18n.translate('xpack.apm.fetcher.error.title', {
defaultMessage: `Error while fetching resource`
}),
text: `${idx(err.res, r => r.status)}: ${idx(err.res, r => r.url)}`
Copy link
Member

Choose a reason for hiding this comment

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

I feel like this could be a bit more user friendly. Maybe a little markup? Do we need the status code? Is there any property from the error (response) we can display instead? (e.g., often errors have a message property that we can surface).

Copy link
Member Author

@sorenlouv sorenlouv Jul 31, 2019

Choose a reason for hiding this comment

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

There is also the error.statusText which we can use instead of status. So instead of 404 it would show Not Found. It is not always as distinguishable as a status code (I'm thinking if the user takes a screenshot and opens a support ticket) but I'm okay with changing it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Full list of status codes and status texts: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

Looks like the texts are unique so might be as good as a status code for us.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added some markup and the statusText. Looks a whole bit nicer now :)

Screen Shot 2019-07-31 at 11 59 39

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@sorenlouv sorenlouv merged commit fc5b0fb into elastic:master Jul 31, 2019
@sorenlouv sorenlouv deleted the display-fetch-errors branch July 31, 2019 11:17
sorenlouv added a commit that referenced this pull request Jul 31, 2019
* [APM] Surface http errors to users

* Fix tests

* Add markup to error message

* Remove transaction type from ui filters
sorenlouv added a commit that referenced this pull request Aug 7, 2019
* [APM] Surface http errors to users

* Fix tests

* Add markup to error message

* Remove transaction type from ui filters
sorenlouv added a commit that referenced this pull request Aug 8, 2019
* [APM] Surface http errors to users

* Fix tests

* Add markup to error message

* Remove transaction type from ui filters
@dgieselaar
Copy link
Member

dgieselaar commented Sep 10, 2019

The mechanism works, but seems like something else was changed and the content is now less than useful:

image

Created a bug: #45263

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:enhancement Team:APM All issues that need APM UI Team support v7.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[APM] Display errors to user instead of swallowing them
3 participants