ioBroker.repositories
ioBroker.repositories copied to clipboard
Added Cloudflare Adapter
Automated adapter checker
ioBroker.cloudflare
:thumbsup: No errors found
- [ ] :eyes: [W171] "common.title" is deprecated in io-package.json
- [ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, zh-cn)
- [ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, zh-cn)
- [ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, zh-cn)
- [ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, zh-cn)
- [ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, zh-cn)
- [ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, zh-cn)
- [ ] :eyes: [W145] Each "common.news" should be translated into all supported languages (en, de, ru, pt, nl, fr, it, es, pl, zh-cn)
- [ ] :eyes: [W400] Cannot find "cloudflare" in latest repository
Add comment "RE-CHECK!" to start check anew
@Marco15453 Alles gut. Checker meldungen bitte ignorieren
Alles klar, habe mich schon gewundert.
Hi,
here my review comments:
- The adapter type "logic" really the best category? Maybe check https://github.com/ioBroker/ioBroker.repositories#types again ... infrastructure? utility?
- For my interest: why nodejs 16.x+ only?
- You do external requests in a hard interval of x seconds (depeneding on user input, default 60), but your axios call do not set any timeout, so in case of network issues it might crerate many parallel requests ... Ideally please set a timeout that secures that all calls are finished within one interval - or switch to a "setTimeout approach" - see best practices in readme of this repo :-) Please also make sure that users can not do a 1s timeout ... enforce "(code wise) a meaningful minimum" ...
- you completely miss error handling ... if one of the axios calls fails on a network level the whole adapter will most likely crash ... think about adding some try/catch
- I personally do not like that the adapter sends log data to slackand discord because this is very custom and I'm sure that users will start to ask next about email, telegram, pushover and all sorts of other ways - where we al have adapters for. If you personally need this maybe consider useing parser adapter and implementing this info sending as a javascript and better somehow have error status as a state or such.
Thank you for checking and adjusting the mentioned points
I'll update it today and i will let you know
Hi,
here my review comments:
- The adapter type "logic" really the best category? Maybe check https://github.com/ioBroker/ioBroker.repositories#types again ... infrastructure? utility?
- For my interest: why nodejs 16.x+ only?
- You do external requests in a hard interval of x seconds (depeneding on user input, default 60), but your axios call do not set any timeout, so in case of network issues it might crerate many parallel requests ... Ideally please set a timeout that secures that all calls are finished within one interval - or switch to a "setTimeout approach" - see best practices in readme of this repo :-) Please also make sure that users can not do a 1s timeout ... enforce "(code wise) a meaningful minimum" ...
- you completely miss error handling ... if one of the axios calls fails on a network level the whole adapter will most likely crash ... think about adding some try/catch
- I personally do not like that the adapter sends log data to slackand discord because this is very custom and I'm sure that users will start to ask next about email, telegram, pushover and all sorts of other ways - where we al have adapters for. If you personally need this maybe consider useing parser adapter and implementing this info sending as a javascript and better somehow have error status as a state or such.
Thank you for checking and adjusting the mentioned points
it has been updated, and all mentioned points should now be fixed.
@Marco15453 Sorry for the long waiting time. The error handling you added is a bit short thought :-)
First of all using catch with await is kind of an anti pattern, but also your next line assumes that the axios gave a response - which is not true when it was failing. So then the adapter would crash in the next line where you e.g. access searchRecord.success ...
Better is to add a try/catch around the relevant block. But in fact I will not block it longer, but you should rethink that.
Welcome in the repository
Ingo