Consul: Refreshing issue in 1.7.0+ UI on node health checks page

[mochery]

Overview of the Issue

When viewing the health checks for a host in the browser and scrolling down the page, the ui will refresh and move to a different position (typically the top) of the page. Makes it near impossible to view health check results in the UI. This happens across browsers (tested chrome, firefox, edge) and periodic reload is seen in the network tab of the browser.

Reproduction Steps

1. Setup client / server with 1.7.0+
2. Create an agent with a number of health checks whose results span more than single screen (will scroll). We have several web services with dependencies shown in the health check results (results can be lengthy).
3. When viewing the node details / health check page at http://webuiservername:8500/ui/dc1/nodes/nodename scroll down the page and the page will refresh to the top or a little further above in the page.

Consul info for both Client and Server

Client info

agent:
        check_monitors = 4
        check_ttls = 0
        checks = 5
        services = 5
build:
        prerelease =
        revision = 95fb95bf
        version = 1.7.0
consul:
        acl = enabled
        known_servers = 3
        server = false
runtime:
        arch = amd64
        cpu_count = 4
        goroutines = 53
        max_procs = 4
        os = linux
        version = go1.12.16
serf_lan:
        coordinate_resets = 0
        encrypted = true
        event_queue = 0
        event_time = 3562
        failed = 0
        health_score = 0
        intent_queue = 0
        left = 0
        member_time = 16427
        members = 144
        query_queue = 0
        query_time = 15

Server info

agent:
        check_monitors = 1
        check_ttls = 0
        checks = 1
        services = 1
build:
        prerelease =
        revision = 95fb95bf
        version = 1.7.0
consul:
        acl = enabled
        bootstrap = false
        known_datacenters = 2
        leader = true
        leader_addr = 192.168.30.132:8300
        server = true
raft:
        applied_index = 187068727
        commit_index = 187068727
        fsm_pending = 0
        last_contact = 0
        last_log_index = 187068727
        last_log_term = 1626
        last_snapshot_index = 187062356
        last_snapshot_term = 1625
        latest_configuration = [{Suffrage:Voter ID:d26e10dd-7f5b-c54a-d702-cc8e0e58fdf5 Address:192.168.30.134:8300} {Suffrage:Voter ID:9b04206f-1f82-edd9-9b83-48d9e3c97b9e Address:192.168.30.133:8300} {Suffrage:Voter ID:4628c4e3-50a1-73f0-9e15-67c71d185a51 Address:192.168.30.132:8300}]
        latest_configuration_index = 0
        num_peers = 2
        protocol_version = 3
        protocol_version_max = 3
        protocol_version_min = 0
        snapshot_version_max = 1
        snapshot_version_min = 0
        state = Leader
        term = 1626
runtime:
        arch = amd64
        cpu_count = 2
        goroutines = 530
        max_procs = 2
        os = linux
        version = go1.12.16
serf_lan:
        coordinate_resets = 0
        encrypted = true
        event_queue = 0
        event_time = 3562
        failed = 0
        health_score = 0
        intent_queue = 0
        left = 0
        member_time = 16427
        members = 144
        query_queue = 0
        query_time = 15
serf_wan:
        coordinate_resets = 0
        encrypted = true
        event_queue = 0
        event_time = 1
        failed = 0
        health_score = 0
        intent_queue = 0
        left = 0
        member_time = 551
        members = 6
        query_queue = 0
        query_time = 1

Operating system and Environment details

Server - RedHat 7.6
Linux client - RedHat 7.6
Windows client - Windows Server 2012 r2 (also have this issue in the UI when viewing a node)

[johncowen]

Hey @mochery

Thanks for reporting this issue, I've been looking into this and unfortunately I can't reproduce just now, but I'm going to keep trying some more things to see if I can get it to do what you are explaining here.

See below for what I'm seeing (using our mock data randomly changing every couple of seconds):

One question I had was, would you be able to check whether this is something you see in versions lower than 1.7.0? We made a fairly large upgrade to our frontend framework between 1.6 and 1.7 so that might provide a clue.

In the meantime I'm going to keep seeing if I can reproduce it.

[mochery]

Hi,

We did have 1.6.1 installed in this same environment and did not see this behavior. I'd take a gif capture for you, but I'd need to obfuscate quite a bit of data. The node I'm looking at at the moment has checks for telegraf, nginx, rabbitmq, and supervisord as a script check running 1m / 5s timeout as "service status" as well as an http check.

If there is any information you need from me please let me know.

[johncowen]

This is great info @mochery thanks! I think that JS framework upgrade hunch might be right

I'd take a gif capture for you, but I'd need to obfuscate quite a bit of data.

I think we have a place where folks can drop us sensitive info. Let me get back to you with that tomorrow, it will save you trying to obfuscate a gif - if you are ok to send us that privately of course.

[mochery]

Ok, i managed to obfuscate some output. When scrolling down the page will refresh and snap back to the top of the page.

[johncowen]

Thanks for the help here @mochery , I have a fix there ^ ready to go.

[mochery]

hi @johncowen I'm not sure if this is the right place to post this, but I installed 1.7.2 which has the fix you mentioned and all works fine there. However iif there was a health check output that spanned greater than the browser window on the page for a single service, it seems this behavior is seen here as well. It will auto scroll to the top of the page. To get there I went Services -> click on a service -> click on the service name in the body -> it'll show the service check result on that host. Sometimes we have health checks that have many dependencies so the output can get a little lengthy.

Here's the URL layout:
http://<consulweb>/ui/<pool>/services/<servicename>/<nodename>/<servicename>

[johncowen]

Hi @mochery

Definitely the right place to post this! Thanks for trying it out and finding this case also! This might explain why it was difficult for me to replicate maybe. I'll take another look and see.

Thanks!

[carmstro]

This same page refresh/scrolling issue also occurs on the Meta Data tab for a Service instance. It started in version 1.7.0 (previous versions are fine) and this makes it impossible to read any of the values below the top 10. As a workaround we are either using an older version or are using query parameters to see the JSON, but it would be great if you could fix the UI.

[johncowen]

Hi @carmstro

Thanks for the extra report, we are currently looking into this! FYI although not ideal you can also turn off Live Updates in the Settings. Hopefully we'll have a proper fix soon.

Thanks,

[johncowen]

Hi @carmstro and @mochery ,

Just a quick update on this, I've merged a fix that should solve this for you both ^. It should be available in the next release. Thanks for your patience!