[Bug] - Rend visibles les échecs opérationnels de l'import RPPS - #61
[Bug] - Rend visibles les échecs opérationnels de l'import RPPS#61Xusifob wants to merge 1 commit into
Conversation
Trois défauts constatés en conditions réelles lors de la première exécution complète sur staging. Une exécution bloquée par le verrou se présentait comme un succès. Après qu'une tâche a été tuée, MySQL n'avait pas encore libéré son verrou nommé : l'exécution suivante a affiché « skipping this run » et s'est terminée avec le code 0. ECS enregistrait donc une réussite, rien ne remontait à Sentry, et le référentiel pouvait rester des semaines sans import — précisément ce que cette commande est censée empêcher. Le code de sortie est désormais un échec, et le message indique la piste du verrou résiduel avec la requête à exécuter pour le vérifier. Le mode debug faisait échouer l'import par épuisement mémoire. Avec la barre de debug active, doctrine-bundle conserve chaque requête exécutée, accompagnée de sa pile d'appels, pour toute la durée du processus. À environ cinq requêtes par ligne, la limite de 2 Gio du conteneur est atteinte vers 250 000 lignes et la tâche est tuée sans message exploitable. APP_ENV valant « staging » sur la tâche planifiée, le debug est actif sauf désactivation explicite, et le setSQLLogger(null) présent ne protège de rien : c'est le mécanisme DBAL 2, la collecte passant désormais par un middleware. La commande refuse maintenant de démarrer, en une seconde plutôt qu'en vingt minutes. La progression était trop espacée pour distinguer une exécution vivante d'une exécution bloquée. Une ligne toutes les 50 000 lignes laissait plusieurs minutes de silence. Passage à 10 000, soit environ 227 lignes par exécution — sans commune mesure avec les 40 000 d'origine. Vérifié : sans --no-debug la commande refuse immédiatement et l'erreur est journalisée en critical ; avec --no-debug elle démarre normalement ; verrou tenu par une autre session, la commande sort en code 1 avec le message de diagnostic. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d5127d0832
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // error. Note the setSQLLogger(null) below does not prevent this: it is the DBAL 2 | ||
| // mechanism, and collection now happens through a middleware. APP_ENV is `staging` on | ||
| // the scheduled task, so debug is on unless it is explicitly turned off. | ||
| if ($this->debug) { |
There was a problem hiding this comment.
In the default development Docker flow, Makefile.import:22 invokes this command without --no-debug, while .env selects APP_ENV=dev, making %kernel.debug% true. This guard therefore always throws when running make import-rpps, which also makes the existing make import-data and make install workflows fail before importing RPPS data. Update that Make target to pass --no-debug, as the production targets already do, or otherwise avoid rejecting this supported entry point.
Useful? React with 👍 / 👎.
1 participant
Trois défauts constatés en conditions réelles lors de la première exécution complète sur staging, tous invisibles en test.
Une exécution bloquée par le verrou passait pour un succès
La première exécution a été tuée pour dépassement mémoire. MySQL n'ayant pas encore libéré son verrou nommé — il ne le fait qu'une fois la connexion morte détectée, ce qui peut dépasser l'intervalle entre deux exécutions — la suivante a affiché « skipping this run » et s'est terminée en code 0.
ECS enregistrait donc une réussite, rien ne remontait à Sentry, et le référentiel pouvait rester des semaines sans import. C'est exactement le mode de défaillance que cette commande est censée supprimer : une exécution silencieusement vide, présentée comme normale, est pire qu'un plantage.
Le code de sortie devient un échec, et le message oriente vers le verrou résiduel en donnant la requête de vérification.
Le mode debug faisait échouer l'import par épuisement mémoire
Avec la barre de debug active, doctrine-bundle conserve chaque requête exécutée avec sa pile d'appels pour toute la durée du processus. À environ cinq requêtes par ligne, la limite de 2 Gio est atteinte vers 250 000 lignes : la tâche est tuée (code 137) sans message exploitable, après vingt minutes.
APP_ENVvalantstagingsur la tâche planifiée, le debug est actif sauf désactivation explicite. LesetSQLLogger(null)déjà présent ne protège de rien : c'est le mécanisme DBAL 2, alors que la collecte passe désormais par un middleware.La cible
import-prod-rpps-fullpasse bien--no-debug, donc l'exécution planifiée n'était pas menacée — mais toute exécution manuelle heurtait le mur. La commande refuse maintenant de démarrer, en une seconde au lieu de vingt minutes.Effet secondaire visible dans les mesures : le débit s'effondrait à mesure que la collecte grossissait, de 388 à 154 lignes/s entre la 50 000e et la 250 000e ligne.
La progression était trop espacée
Une ligne toutes les 50 000 lignes laissait plusieurs minutes de silence, impossible à distinguer d'un blocage. Passage à 10 000 : environ 227 lignes par exécution, sans commune mesure avec les 40 000 d'origine.
Vérification
--no-debug, refus immédiat, erreur journalisée encritical;--no-debug, démarrage normal ;185 tests au vert, phpstan et phpcs sans erreur.
🤖 Generated with Claude Code