[QUESTION] 2.0.6 Widgets timeout errors
henkiewie opened this issue · 22 comments
Environment
Self-Hosted (Docker)
Version
2.0.6
Describe the problem
today at 12:07:47{
today at 12:07:47 headers: {},
today at 12:07:47 enableInsecure: false,
today at 12:07:47 acceptCodes: 'null',
today at 12:07:47 maxRedirects: 'null'
today at 12:07:47}
today at 12:07:47{
today at 12:07:47 headers: {},
today at 12:07:47 enableInsecure: false,
today at 12:07:47 acceptCodes: 'null',
today at 12:07:47 maxRedirects: 'null'
today at 12:07:47}
today at 12:07:47{
today at 12:07:47 headers: {},
today at 12:07:47 enableInsecure: true,
today at 12:07:47 acceptCodes: 'null',
today at 12:07:47 maxRedirects: 'null'
today at 12:07:47}
Additional info
updated to 2.0.6 yesterday (using latest label) gives errors in the log and the view.
widgets are giving back values, but still give errors.
turning off proxy makes no difefrence. (- type: gl-current-cpu useProxy: false).
Going back to 2.0.5 solves the issue.
console gives time-out;
CoolConsole.js:18 Stack Trace
Error: timeout of 500ms exceeded
i @ CoolConsole.js:18
l @ ErrorHandler.js:27
error @ WidgetMixin.js:75
(anonymous) @ WidgetMixin.js:123
Promise.catch (async)
(anonymous) @ WidgetMixin.js:122
makeRequest @ WidgetMixin.js:114
fetchData @ GlancesMixin.js:26
update @ WidgetMixin.js:67
(anonymous) @ WidgetMixin.js:71
2createError.js:16 Uncaught (in promise) Error: timeout of 500ms exceeded
at t.exports (createError.js:16:15)
at XMLHttpRequest.w.ontimeout (xhr.js:130:14)
Please tick the boxes
- You are using a supported version of Dashy (check the first two digits of the version number)
- You've checked that this issue hasn't already been raised
- You've checked the docs and troubleshooting guide
- You agree to the code of conduct
GitHub is where people build software. More than 73 million people use GitHub to discover, fork, and contribute to over 200 million projects.
Welcome to Dashy 👋
It's great to have you here, but unfortunately your ticket has been closed to prevent spam. Before reopening this issue, please ensure the following criteria are met.
Issues are sometimes closed when users:
- Have only recently joined GitHub
- Have not yet stared this repository
- Have not previously interacted with the repo
Before you reopen this issue, please also ensure that:
- You have checked that a similar issue does not already exist
- You have checked the documentation for an existing solution
- You have completed the relevant sections in the Issue template
Once you have verified the above standards are met, you may reopen this issue. Sorry for any inconvenience caused, I'm just a bot, and sometimes make mistakes 🤖
If you could also share the relevant parts of your config file, that would be helpful.
Looking at the error, looks like this part is the cause: Error: timeout of 500ms exceeded
You can try setting timeout to a larger value, on the failing widgets, with: timeout: 2000
Example
- type: gl-current-cpu
timeout: 5000
options:
hostname: https://glances.dns-device.local
I've increased the default timeout a bit, and have also added instructions for setting higher timeout to the troubleshooting guide
/close
If you're enjoying Dashy, please consider Staring the repo. It helps new users discover it, and will prevent your issues from being auto-closed due to lack of GitHub activity.
Hi LIssy,
timeout: 2000. Did not work for me. 4000 did 😄 .
here's the part of the config.yml. The URL's are from my internal pi-hole DNS. So all go through Nginx proxy manager on the same machine.
The PI is on heavy duty 😃 .
sections:
- name: PI CPU Temperature
icon: hl-raspberrypi
widgets:
- type: gl-cpu-temp
useProxy: false
timeout: 2000
updateInterval: 5
options:
hostname: https://glances.rpi-lite.lan
id: 0_1615_glcputemp
displayData:
sortBy: default
rows: 1
cols: 1
collapsed: false
hideForGuests: false
- name: PI CPU Usage
icon: hl-raspberrypi
widgets:
- type: gl-current-cpu
useProxy: false
timeout: 2000
options:
hostname: https://glances.rpi-lite.lan
id: 0_950_glcurrentcpu
displayData:
sortBy: default
collapsed: false
hideForGuests: false
rows: 1
cols: 1
- name: PI Memory Usage
icon: hl-raspberrypi
widgets:
- type: gl-current-mem
useProxy: false
timeout: 2000
options:
hostname: https://glances.rpi-lite.lan
id: 0_1351_glcurrentmem
displayData:
sortBy: default
rows: 1
cols: 1
collapsed: false
hideForGuests: false
Hi,
I have the same error but i don't use PI CPU.
My config below
https://pastebin.com/2uNf14aG
Going back to 2.0.5 solves the issue.
@Al4ndil, Just up the timeout
Sorry but can you explain me more how to make this in my case ?! I don't use widget and i don't know where i must put "timeout : 2000"...
Sure, there's an example above in ⬆️ this comment, I'll paste it below for ya, but basically just put timeout: 5000
in whichever widget is failing.
This is explained more here, in the widget docs.
And if you're ever unsure of where something goes, you can reference the configuring docs.
Originally posted by lissy93 March 29, 2022
Looking at the error, looks like this part is the cause: Error: timeout of 500ms exceeded
You can try setting timeout to a larger value, on the failing widgets, with: timeout: 2000
Example
- type: gl-current-cpu
timeout: 5000
options:
hostname: https://glances.dns-device.local
@Lissy93 I'm sorry again but i don't use any widget. So where i need to put timeout ?
Perhaps i don't understand but you mentionned "widget" each time you mentionned "timeout".
This ticket is about widget timeout errors, so not sure how you are getting this error message if you don't have a widget...?
Sorry, don't think I understand what you mean, could you explain the issue further? It might be helpful to see a screenshot, and also any console messages (here's instructions if you're unsure how)
In this pastebin, there is all my conf.yml
https://pastebin.com/2uNf14aG
And i had the same error with 2.0.6 in my logs
#581 (comment)
I resolve this with a downgrade to 2.0.5
Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.
Could you share:
- A screenshot of the issue
- The output of the console (here's instructions if you're unsure how)
- (it can't be the same as above, as that's a widget error, and you don't have any widgets).
You config looks fine 👍
No problem on the web ui.
https://i.imgur.com/mECLGFk.png
Brave's console
o937511.ingest.sentry.io/api/5887934/envelope/?sentry_key=3138ea85f15a4fa883a5b27a4dc8ee28&sentry_version=7:1 Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
Dashy V2.0.6 🚀
o937511.ingest.sentry.io/api/5887934/envelope/?sentry_key=3138ea85f15a4fa883a5b27a4dc8ee28&sentry_version=7:1 Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
o937511.ingest.sentry.io/api/5887934/envelope/?sentry_key=3138ea85f15a4fa883a5b27a4dc8ee28&sentry_version=7:1 Failed to load resource: net::ERR_BLOCKED_BY_CLIENT
Doesn't seem to be any errors.
What problem are you experiencing if it's not on the UI?
Sorry but I'm very confused....
This ticket is about widget timeout errors, but you said you're not using any widgets. And you don't have any issues on the UI, nor any errors in the console. So it sounds like everything's working fine. Without a description of the issue, I cannot help.
Hmmm the errors are on the logs of Dashy
https://i.imgur.com/z4D8VuC.png
I don't have these errors with 2.0.5
Ahhhh, lol now I know what you mean. I thought u were trolling me!
So those aren't errors, they're nothing to worry about, it's described in more detail in the Troubleshooting Guide, but is just info.
The status check info was a mistake tho, it's this line here, and will be removed in the next version. But it doesn't affect anything, so you're all good.
No no no ! I wouldn't have allowed myself to troll you :)
Thx for your answer ! :)
The fix for this issue has now been released in 2.0.7 ✨
If you haven't done so already, please update your instance to 2.0.7
or later. See 2.0.7 for full info.
Feel free to reach out if you need any more support. If you are enjoying Dashy, consider supporting the project.
Hi Lissy,
There seems to be an error in the 2.0.7 version using the the item target openingmethod. It is not used anymore and is falling back to the default in appconfig.defaultOpeningMethod: newtab
. So if the item is target: modal and the default is newtab its using newtab and vice versa. Going back to 2.0.6 solves it for me.
I see no errors in the browser console. (Some of my docker containers use their own web server dissallowing Xframe options so modal is not an option). Want me to make a bug report? I think the bot is closing it automatic 😄 .
Greetings Henk.
Oops, my bad, I did a LOT of refactoring for items, and looks like I messed up the target attribute, thanks for raising.
I pushed a fix out in a784a2f which is now merged :)
Problem fixed. Have a nice (easter) weekend.
Greetings,
Henk