Tibber: extend connection retry delay to 5s #18646
Conversation
GrimmiMeloni
added
enhancement
There was a problem hiding this comment.
Ich würde vorschlagen, hier auf einen höheren Wert zu gehen. Bei 5 Sekunden sind wir schon bei 60 Requests / 5 Min (Limit: 100 Requests / 5 Min). Wenn da noch ein zweiter Dienst die API nutzt wird es schnell eng. Im Sinne einer Cool-Down-Phase nachdem das Limit gerissen wurde, würde ich eher 20 oder 30 Sekunden vorschlagen.
Dem stimme ich zu. Das Problem ist, daß die 429 nirgends exponiert wird. Es ist also nicht möglich, von außen zu unterscheiden ob ein Limit gerissen wurde, oder ob der Connect auf Grund eines temporären Fehlers auftritt. Die Argumentation mit parallelen Clients kann ich zwar nachvollziehen, aber die sind auch eine komplette Unbekannte. Wieviele Clients (und mit welcher Request rate?) soll man jetzt annehmen? Wenn die Summe groß genug wird, ist kein Wert den wir hier definieren richtig. 😢 Vielleicht ist es besser wir lassen den Client "aufgeben", und bauen dann außen ein Exponentielles Backoff drumherum. Das können wir aber auch in einem dedizierten PR erledigen. Das Default Retry Intervall von 1s erscheint mir jedenfalls viel zu aggressiv - so oder so. |
|
Vielleicht löst Tibber ja irgendwann mal das hausgemachte Problem... |
|
Soeben erfolgreich mit dem aktuellen nightly getestet. Nachdem ich eine Überschreitung des Rate-Limit herbeigeführt habe, kam für ein paar Minuten der erwartete Fehler, aber durch das höhere Retry-Interval fängt es sich dann ohne manuelles Eingreifen wieder. Danke! |
fix #18635