When the server is not available, the frontend should inform the admin

[gorkem-bwl]

When the server is not available, the frontend should inform the admin.

Main flow can be as follows:

1. FE checks the BE health api endpoint every 2 seconds.
2. In case of an issue, FE shows a toast message "Checkmate server is not running or has issues. Please check.". Admin may close the toast message, but in case of an error it should provide the same message again.
3. If another health api check gets a 200 code back, it shows "Checkmate server is running properly.". Each toast message has a standart delay and after this delay the message can disappear, or admin can also close the message.

FYI @ajhollid for the BE endpoint.

[jasneetsingh6114]

Hey , I found this issue interesting to solve if possible can you assign this issue to me

[gorkem-bwl]

@jasneetsingh6114 can you write how you are going to implement this? Also do you have any previous, similar contributions that I can check?

[jasneetsingh6114]

Hi @gorkem-bwl,
While I don’t have prior experience contributing to any open-source projects like this but I do have hands-on experience with the projects that I have created personally. Additionally, I’m eager to learn and apply my skills to deliver a solution that meets the project’s requirements.

Here’s how I plan to implement this feature:

Polling Mechanism:
Use a frontend library (React with Axios as it is already in use in the project) to periodically check the health API endpoint every 2 seconds.

State Management:
Maintain a state variable to track the backend's health status.
Trigger UI updates only when the state changes (e.g., from healthy to unhealthy or vice versa).

Notification System:
Use React Toastify (as it is already in use in the project) to display user-friendly toast messages for the admin.
Ensure error messages reappear for persistent issues and success messages are shown when the server recovers.

User Experience Enhancements:
Add dismissible toasts that auto-expire after 5 seconds.
Ensure toasts do not spam the admin by triggering only on state changes.
I am confident in my ability to research and adapt quickly and I can implement this feature effectively.

[gorkem-bwl]

Thanks @jasneetsingh6114 - please get an understanding of the codebase before starting. Also make sure you check .github/pull_request_template.md file to have an understanding of what is expected from a pr.

[jasneetsingh6114]

Hey @gorkem-bwl
Can you please share the details of health API endpoint?

[gorkem-bwl]

Hey @gorkem-bwl Can you please share the details of health API endpoint?

For now you can assume it will return "ok" from /health and move ahead. @ajhollid will come up with an implementation you can use soon.

[ajhollid]

Hey @jasneetsingh6114,

Polling a health check endpoint is overkill for this issue, there is no need to add that kind of traffic overhead.

We already have an Axios reponse interceptor:

this.axiosInstance.interceptors.response.use(
	(response) => response,
	(error) => {
		if (error.response && error.response.status === 401) {
			dispatch(clearAuthState());
			dispatch(clearUptimeMonitorState());
			navigate("/login");
		}
		return Promise.reject(error);
	}
);

All you need to do is modify it slightly to deal with error.request as well as error.response.

Axios Docs for your reference.

In general, polling should be used very sparingly and there should be a very good reason to do so.

[gorkem-bwl]

Ah ok Alex, thanks for the clarification.

[ajhollid]

Ah ok Alex, thanks for the clarification.

No problem, sorry I was late to the discussion, I hope you didn't go too far down the health check path @jasneetsingh6114

Give me a ping if you'd like to discuss the implementaiton 👍