Bug #8083
closed
WebHooks fail with Net::ReadTimeout
0%
Description
Si un WebHook ou SystemWook met "trop" longtemps à répondre, gitlab/sidekiq interprète que le hook a échoue et le relance indéfiniment.
Related issues
Updated by Brétel Foudil over 10 years ago
Comme indiqué https://github.com/gitlabhq/gitlabhq/issues/3794, j'ai essayé dans mon script PHP de répondre au plus tôt par
header("Status: 200");
header('Content-Type: text/html; charset=utf-8');
echo("OK"); flush(); ob_flush();
Mais l'output passant par le serveur web ne semble pas flushé (à moins que ce ne soit curl).
J'ai essayé de modifier en dur
# app/models/web_hook.rb default_timeout 10
en le passant à 10000, mais rien n'y fait.
Le contournement consiste à lancer au plus vite un autre script pour effectuer le travail proprement dit.
Updated by Brétel Foudil over 10 years ago
Accessoirement, les admin doivent vérifier la queue Retries dans Admin area > Background Jobs.
Updated by Brétel Foudil over 10 years ago
- Status changed from New to Resolved
- Assigned To set to Brétel Foudil
La solution de contournement consiste à sortir rapidement du hook et confier les tâche lourdes à un process fils.
Updated by Brétel Foudil over 10 years ago
La dernière version 7.2.3 ajoute un paramètre de configuration @webhook_timeout@ positionné à 120 secondes.
Updated by Brétel Foudil over 10 years ago
- Related to Task #8298: gestion des background jobs échoués added