Open zcrt opened 1 month ago
Im guessing this is due to the fact that these api calls are doing async work in their backends, and or are taking longer than your script is waiting before it sends out a new call.
This would then end up using all available resources / server connections somewhere along the stack.
It happens in about 6% of the cases, likely directly after another for a few organisations.
Could we fix it by adding a retry or random sleep here? Or is there a way to allow more connections?
Describe the bug Connection reset/refused/timeout on multiple requests. Possibly to octopoes. Behaviour exists when using the API, but that is less of a problem. More of a problem is the actions that take place on multiple organisations, such as rerunning bits.
To Reproduce Try adding many organisations through the API or Try rerunning all bits when there are many organisations
Expected behavior Smooth Octopoes/KAT
OpenKAT version https://github.com/minvws/nl-kat-coordination/commit/980415375c372e6f32086ce55078e8e5533f456b
Failed reasons include: 'timed out', '[Errno 104] Connection reset by peer', '[Errno 111] Connection refused'