DescriptionWhen a service/widget host is unreachable (e.g., a sleeping laptop running a Glances agent), the whole dashboard hangs for an extended period rather than just showing an error on that one tile. With multiple unreachable hosts in the config, the hangs appear to compound sequentially — the page waits through a full timeout for the first unreachable host, then the next, and so on, rather than fetching all widgets in parallel. Steps to reproduce: Configure several service groups, each with a Glances widget pointed at a different host. Observed: The entire page becomes unresponsive/hangs for what appears to be 60+ seconds per unreachable host, compounding when multiple hosts are down, before the reachable tiles finally render. Expected: Widgets should load independently/in parallel so that unreachable hosts only affect their own tile (showing an API error) without blocking the rest of the dashboard. Environment: Confirmed on both the latest tag (dev build, package.json reporting 2.1.0) and the stable v2.0.0 release — same behavior on both, so this doesn't appear to be a recent regression specific to one version. Ask: Would a configurable per-widget timeout (shorter than whatever the current default is) or parallelized widget fetching be feasible? Either would help a lot for home-lab setups where multiple hosts aren't guaranteed to always be online. homepage versionv2.0.0, and 2.1.0 Installation methodDocker Configurationservices:
homepage:
image: ghcr.io/gethomepage/homepage:v2.0.0
container_name: homepage
restart: unless-stopped
env_file:
- .env
ports:
- "3002:3000"
environment:
- HOMEPAGE_ALLOWED_HOSTS=10.0.0.153:3002,thestash.example.ts.net:3002
volumes:
- /DATA/AppData/homepage:/app/config
- /var/run/docker.sock:/var/run/docker.sock:ro
Container Logsthestash@thestash:/DATA/AppData/homepage$ docker logs homepage --since 10m 2>&1 | tail -100 Browser Logs[Error] Failed to load resource: the server responded with a status of 500 (Internal Server Error) (proxy, line 0) TroubleshootingConfirmed via direct curl that all reachable hosts respond correctly and instantly at the API level — the freeze is not a real connectivity problem for those hosts. |
Replies: 3 comments
|
Thats not exactly what's happening, despite the AI pseudo-analysis. Each widget is absolutely independently fetched using swr, what I assume is happening is your browser hitting a max connections at once since glances in particular fans out to a bunch of different requests. In the end, Id say it's not such a typical use case, having a widget for things that are often offline. Yes, we could implement a timeout, but that feels like a core change for a small benefit (no offense =). Alternatively you could put your homepage behind an HTTP/2 reverse proxy and I suspect this wouldnt be an issue. Or drop the dead server widgets, of course. |
|
Thanks for the reply and guidance, as this is totally a learning process and new venture for me, hence the AI pseudo-analysis. No need to make a core change for me as the HTTP/2 reverse proxy solves my issue entirely. I can't wait to learn and do more with Homepage! Thanks again! |
|
This discussion has been automatically closed because it was marked as answered. See our contributing guidelines for more details. |
Thats not exactly what's happening, despite the AI pseudo-analysis. Each widget is absolutely independently fetched using swr, what I assume is happening is your browser hitting a max connections at once since glances in particular fans out to a bunch of different requests.
In the end, Id say it's not such a typical use case, having a widget for things that are often offline. Yes, we could implement a timeout, but that feels like a core change for a small benefit (no offense =). Alternatively you could put your homepage behind an HTTP/2 reverse proxy and I suspect this wouldnt be an issue. Or drop the dead server widgets, of course.