-
Notifications
You must be signed in to change notification settings - Fork 40
Description
Users should be notified upon logging in that there is no connection with the Specify Worker.
1. Automatic Worker Status Check
- After a user logs in, Specify should automatically check whether the Specify Worker process is reachable and its database connection is healthy.
- This check must complete (success or failure) regularly.
2. User-Facing Warning Banner
- If the worker is unreachable or its database connection fails, display a dialog.
- The dialog could read:
“Warning: The Specify Worker is unavailable. The WorkBench, Batch Editing, and Record Merging will be unavailable until this is resolved. Please contact your system administrator, or if you are hosted on Specify Cloud, [email protected]” - This dialog should reappear whenever the user tries to use the WorkBench, Batch Edit, Record Merging, or any other activity that requires the worker.
- If the page is refreshed or the user logs in again and the worker is still down, the warning banner shall automatically reappear.
3. Technical Logging
- Whenever the application cannot reach the worker or its database, log a warning in the browser console.
- Include the timestamp and a brief error description to aid in troubleshooting.
4. Extensible Health Report
- Design the worker’s health-check interface so it can later include additional services (e.g.,
web-asset-server,report-runner-service) without changing the application logic. - Treat any critical service listed as “down” in that report the same way as a database failure.
Reported by: @FedorSteeman at Natural History Museum of Denmark
From @melton-jason in #6490 (comment)
Thank you for the comment @FedorSteeman!
It would be nice, if the worker process could somehow report back to the UI what it is dealing with, like -in this case- the database connection not working
I agree: it would be beneficial to have some indication of the worker status accessible in the primary application. The worker is really just traditionally another Specify instance (using the same underlying Docker image(s) with a different starting command), so I'm imagining a useful and simple solution be that we could define an endpoint whose purpose is to check the database connection: that way, the (frontend) application could ask the worker whether or not it has a successful database connection. Perhaps this could be generalized even further for connection across other services (report running, asset server, message broker (redis), etc.).
I can open up a further Issue to tackle transparency between the worker and main specify instance, and we can discuss different solutions and design. Let us know if you have a vision in mind regarding this feature!