Not possible to add new monitors to editing status page

[mantoniocc]

⚠️ Please verify that this bug has NOT been raised before.

• [X] I checked and didn't find similar issue

🛡️ Security Policy

• [X] I agree to have read this project Security Policy

Description

Hi guys, I have created some monitor and then I have created a status page. I could be able to add monitors created to status page successfully. However, I have added some additional monitors. Therefore, I wanted to add those new monitors to the status page. So I click edit status page button, but I couldn't be able to add the new monitors.

👟 Reproduction steps

• Add X monitors
• Create a status page
• Add monitors available to status page
• Save changes
• After create X additional monitors.
• Then, come back to status page previously created and click to edit status page button.
• No monitors available. Add one (this message is showed). Despite that I created new monitors.

👀 Expected behavior

Be able to add additional monitors to status page to editing. There is a workaround that consists to create again the status page. But is not very productive.

😓 Actual Behavior

Is not possible to add new monitors (previously created to editing status page)

🐻 Uptime-Kuma Version

1.15.1

💻 Operating System and Arch

Mac OS big Sur

🌐 Browser

Chrome Versión 85.0.4183.83 (Build oficial) (64 bits)

🐋 Docker Version

20.10.6

🟩 NodeJS Version

No response

📝 Relevant log output

No response

[Drehmini]

🐻 Uptime-Kuma Version 1.15.1 💻 Operating System and Arch Ubuntu 20.04 LTS/Arm64 🌐 Browser Chrome Version 101.0.4951.67

I am not experiencing this issue. This may be a browser caching issue. Have you tried using an incognito mode window after adding your services, to rule out a browser issue?

[mantoniocc]

Hi @Drehmini Yes, I have. I tried using incognito mode (Chrome) and Safari, but I continue experimenting the same behavior. I created my status page when I only had 3 monitors. After that, I created 5 additional monitors and I tried to add them to the status page previously created. For me it wasn't possible to do.

Let's me show an example:

I have created several monitors.

I'm going to create a new status page. Option Add a monitor is available and shows a list of monitors. I picked one. Then, save changes successfully.

After that, I clic on Edit status page, to add more monitors. But No monitors available is displayed.

[Drehmini]

Is it possible that you are keeping the status page open, adding monitors in a separate tab, and then expecting them to show up? Or, maybe, are you adding the monitors and then using the back button to get back to editing the status page?

Either way, you should be able to refresh the status page to get them to show up.

A scenario that you should try is (if you haven't already):

1. In a regular browser window, create the status page with existing monitors.
2. In a regular browser window, save the status page
3. In a regular browser window, add new monitors
4. Edit the status page in an incognito window and verify that you're able to see the monitors.

[louislam]

Similar problem was reported before: https://github.com/louislam/uptime-kuma/issues/1465 I am not sure how to reproduce this, as the monitor list is loaded from WebSocket. It should not be cached.

[mantoniocc]

I tried with demo https://demo.uptime.kuma.pet:27000/ and same problem.

[louislam]

I suspected that it is related to MacOS, since both reports are using MacOS.

Do you have Android or Windows device to test it?

[tupcakes]

I'm seeing this also on windows with firefox and edge. Currently on 1.16.1 with firefox 101.0.

[sir-andreas]

Same here: Win 10, Chrome 102, Uptime Kuma on 1.16.1

[Computroniks]

I can't reproduce at all on Kali Rolling 2021.1 and chrome 99.0.4844.82 or Win11 chrome 101.0.4951.67 using commit 11243a6ca16a52e472507cbe1ed56f9f6075027d as well as Tag 1.16.1

I have tried having the dashboard and status page open in seperate tabs and they both seem to work fine with the monitor appearing when the dropdown is clicked as expected.

I have a feeling that this may just be some weirdness with individual environments or some unknown behavior in node given that this sort of thing seems to only sometimes be reproducible and seems to clear up after a while (#1465)

[louislam]

I can't reproduce at all on Kali Rolling 2021.1 and chrome 99.0.4844.82 or Win11 chrome 101.0.4951.67 using commit 11243a6 as well as Tag 1.16.1

I have tried having the dashboard and status page open in seperate tabs and they both seem to work fine with the monitor appearing when the dropdown is clicked as expected.

I have a feeling that this may just be some weirdness with individual environments or some unknown behavior in node given that this sort of thing seems to only sometimes be reproducible and seems to clear up after a while (#1465)

Since @mantoniocc could reproduced the problem in the demo site, it should be a frontend issue.

[Computroniks]

I can't reproduce on the demo site either.

It is most likely frontend but I wouldn't like to say with 100% certainty just due to the weird nature of the issue and how it seems to come and go. Given the cross browser reports the OS and browser can be ruled out. The only issue I can think of is perhaps there is an issue with detecting if there is a socket client in the room meaning that no updated monitor list is sent to the status page when a new monitor is added although this would only be an issue if the status page is open in a seperate tab. There could also possibly be an issue with this request not being processed by vue.

To rule this out, could someone who can reproduce this issue do the following:

1. Open up the dashboard and status page in two seperate tabs
2. Open developer tools for the status page tab
3. Navigate to the network screen
4. Enter edit mode on the status page
5. Click on the web socket request in dev tools: It is the request that says ?EIO=4&transport=websocket. To view the messages just click on the messages tab
6. In the dashboard tab, add a new monitor
7. Look at the messages, see if there is one that looks a bit like this 42["monitorList",{"1":{"id":1,"name":"www.sidingsmedia.com","url":"https://www.sidingsmedia.com","method":"GET","hostname":null,"port... at around the time you saves the new monitor.

This test is to rule out issues with clients being detected in the socket room. It does not rule out an updated monitor list not being sent on page reload

[louislam]

I just dig into the code again, found out that it should be related to some sort of race condition and loadedData is not set to true

https://github.com/louislam/uptime-kuma/blob/436bc13aeb2ea1f25b2b6068bf3d5ed1693d1c8d/src/pages/StatusPage.vue#L240-L248

[louislam]

1.17.0-beta has been released with the patch, feel free to try and let me know whether it is fixed.

[TheEmpty]

Just experienced this on a fresh install from docker. Version page reports Version: 1.17.1. Using :latest tag, resolving to docker.io/louislam/uptime-kuma@sha256:a4eab252e5a27ead9e92f04d755d6cc968be923b277aae42ac8cf633e2da3b15.

Firefox 91.10.0esr (64-bit) on MacOS 11.6.5 (Big Sur).

Doing a kubectl rollout restart deployment/uptime-kuma to restart the container did not resolve issue.