Bug rapporté depuis le backoffice : cliquer « 🔁 Hash » sur une nouvelle
version renvoyait un 500 Internal Server Error générique (« Please contact
the server administrator at postmaster@asterionvr.com »). L'opérateur ne
pouvait donc plus signer une release après upload SFTP du ZIP.
Root cause : hash_file('sha256', $zip) sur un fichier de 14 Go via le SAN
mutualisé OVH prend 5-10 min. Le max_execution_time PHP par défaut (30-60s)
tue le process bien avant. Apache remonte alors 500 avec son boilerplate
par défaut, sans log utile pour l'opérateur.
Fix en défense en profondeur :
1. set_time_limit(0) + ignore_user_abort(true) au début de run(). Couvre
TOUS les callers (admin web, cron, CLI). ignore_user_abort évite qu'un
refresh de l'onglet backoffice interrompe un hash en cours (10 min = ~un
café — l'opérateur peut être tenté de refresh).
2. Passage de hash_file() → hash_init + hash_update_stream en boucle
16 Mo par chunk. Deux bénéfices :
• flush() entre chaque chunk = heartbeat pour le proxy Apache/OVH front,
évite un timeout côté serveur web même si PHP a le droit de continuer.
• set_time_limit(300) glissant à chaque chunk = si un chunk prend +5 min
c'est vraiment un disque HS, pas juste un gros fichier — on n'est pas
bloqué sur un unique timer géant.
Mémoire : hash_update_stream() ne buffere pas, streaming pur, aucun risque
d'OOM même sur 14 Go.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
j.foucher
46d7c461c5