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][Service Map] ML health status not being updated after changing time range #80335

Closed
cauemarcondes opened this issue Oct 13, 2020 · 1 comment · Fixed by #80430
Closed
Assignees
Labels
apm:service-maps Service Map feature in APM apm:test-plan-regression bug Fixes for quality problems that affect the customer experience Team:APM All issues that need APM UI Team support v7.10.0

Comments

@cauemarcondes
Copy link
Contributor

cauemarcondes commented Oct 13, 2020

Open service map, change the time range to the last 7 days, after the new map is loaded the ML health status is still showing the old value. It updates after navigating to the service page and back to the service map page.

ezgif com-gif-maker (1)

@cauemarcondes cauemarcondes added [zube]: Inbox apm:service-maps Service Map feature in APM bug Fixes for quality problems that affect the customer experience Team:APM All issues that need APM UI Team support v7.10.0 labels Oct 13, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/apm-ui (Team:apm)

@smith smith self-assigned this Oct 13, 2020
smith added a commit to smith/kibana that referenced this issue Oct 13, 2020
When `add`ing an element with an already existing ID, it will use the already existing data instead of setting new data. This made it so when you change the time picker the element health statuses would not update.

When we get new elements, replace the existing data for existing elements.

Fixes elastic#80335.
smith added a commit that referenced this issue Oct 14, 2020
When `add`ing an element with an already existing ID, it will use the already existing data instead of setting new data. This made it so when you change the time picker the element health statuses would not update.

When we get new elements, replace the existing data for existing elements.

Fixes #80335.
smith added a commit to smith/kibana that referenced this issue Oct 14, 2020
When `add`ing an element with an already existing ID, it will use the already existing data instead of setting new data. This made it so when you change the time picker the element health statuses would not update.

When we get new elements, replace the existing data for existing elements.

Fixes elastic#80335.
smith added a commit to smith/kibana that referenced this issue Oct 14, 2020
When `add`ing an element with an already existing ID, it will use the already existing data instead of setting new data. This made it so when you change the time picker the element health statuses would not update.

When we get new elements, replace the existing data for existing elements.

Fixes elastic#80335.
cauemarcondes pushed a commit that referenced this issue Oct 14, 2020
When `add`ing an element with an already existing ID, it will use the already existing data instead of setting new data. This made it so when you change the time picker the element health statuses would not update.

When we get new elements, replace the existing data for existing elements.

Fixes #80335.
cauemarcondes pushed a commit that referenced this issue Oct 14, 2020
When `add`ing an element with an already existing ID, it will use the already existing data instead of setting new data. This made it so when you change the time picker the element health statuses would not update.

When we get new elements, replace the existing data for existing elements.

Fixes #80335.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apm:service-maps Service Map feature in APM apm:test-plan-regression bug Fixes for quality problems that affect the customer experience Team:APM All issues that need APM UI Team support v7.10.0
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants