mlflow: épingle anyio, dont une reconstruction a cassé le serveur #131

Merged

gabriel merged 1 commit from lenaic/130-mlflow-anyio into develop

2026-09-03 15:47:09 +00:00

lenaic commented

2026-09-03 15:22:32 +00:00

Owner

Ce que ça change

Une ligne dans infra/compose/mlflow/requirements.txt : anyio<4.15.

Closes #130

Ce qui s'est passé

MLflow est tombé le 3 septembre à 17 h 08, pendant le déploiement de la mise en
production, et l'a fait échouer : wait: true attend une pile saine, elle ne l'est jamais
devenue.

AttributeError: module 'anyio' has no attribute 'from_thread'
  starlette/middleware/wsgi.py, ligne 136

anyio 4.15.0 est passé aux imports paresseux et n'expose plus from_thread en attribut.
starlette 1.6.0 l'appelle pourtant après un simple import anyio.

Le fichier épinglait mlflow==3.15.2 et l'expliquait très bien — « une image
reconstruite six semaines plus tard doit poser les mêmes octets » — mais s'arrêtait aux
dépendances directes. L'image tournait « Up 21 hours (healthy) » le matin même, avec ces
mêmes fichiers.

Preuve

Vérifié dans un conteneur jetable avant d'écrire la ligne :

$ docker run --rm python:3.12-slim sh -c \
    'pip install -q mlflow==3.15.2 psycopg2-binary==2.9.12 boto3==1.43.86 "anyio<4.15"; ...'

anyio      4.14.2
starlette  1.6.0
mlflow     3.15.2
from_thread accessible : True
starlette.middleware.wsgi s'importe : oui

Ce que ça ne règle pas

La pile mlflow porte build: true, donc son image est reconstruite à CHAQUE
déploiement — et postgres aussi. Cet épinglage ferme ce trou-ci, pas la classe entière :
la prochaine dépendance indirecte non épinglée fera pareil.

Le #130 porte la décision : soit build: always reste et l'épinglage devient une règle,
soit il passe à missing et une reconstruction se demande. Ça se tranche, ça ne se subit
pas au prochain déploiement.

Une remarque au passage : starlette.middleware.wsgi est déprécié et sera retiré. MLflow
s'en sert encore. Ce n'est pas urgent, mais ça datera la prochaine montée de version.

## Ce que ça change Une ligne dans `infra/compose/mlflow/requirements.txt` : `anyio<4.15`. Closes #130 ## Ce qui s'est passé MLflow est tombé le **3 septembre à 17 h 08**, pendant le déploiement de la mise en production, et l'a fait échouer : `wait: true` attend une pile saine, elle ne l'est jamais devenue. ``` AttributeError: module 'anyio' has no attribute 'from_thread' starlette/middleware/wsgi.py, ligne 136 ``` `anyio 4.15.0` est passé aux imports paresseux et n'expose plus `from_thread` en attribut. `starlette 1.6.0` l'appelle pourtant après un simple `import anyio`. **Le fichier épinglait `mlflow==3.15.2` et l'expliquait très bien** — « une image reconstruite six semaines plus tard doit poser les mêmes octets » — mais s'arrêtait aux dépendances directes. L'image tournait « Up 21 hours (healthy) » le matin même, avec ces mêmes fichiers. ## Preuve Vérifié dans un conteneur jetable avant d'écrire la ligne : ``` $ docker run --rm python:3.12-slim sh -c \ 'pip install -q mlflow==3.15.2 psycopg2-binary==2.9.12 boto3==1.43.86 "anyio<4.15"; ...' anyio 4.14.2 starlette 1.6.0 mlflow 3.15.2 from_thread accessible : True starlette.middleware.wsgi s'importe : oui ``` ## Ce que ça ne règle pas **La pile `mlflow` porte `build: true`, donc son image est reconstruite à CHAQUE déploiement** — et `postgres` aussi. Cet épinglage ferme ce trou-ci, pas la classe entière : la prochaine dépendance indirecte non épinglée fera pareil. Le #130 porte la décision : soit `build: always` reste et l'épinglage devient une règle, soit il passe à `missing` et une reconstruction se demande. Ça se tranche, ça ne se subit pas au prochain déploiement. Une remarque au passage : `starlette.middleware.wsgi` est déprécié et sera retiré. MLflow s'en sert encore. Ce n'est pas urgent, mais ça datera la prochaine montée de version.

lenaic added the

labels

2026-09-03 15:22:32 +00:00

lenaic self-assigned this

2026-09-03 15:22:32 +00:00

lenaic added 1 commit

2026-09-03 15:22:32 +00:00

mlflow: épingle anyio, dont une reconstruction a cassé le serveur

Intégration / Qualité du code Python (pull_request) Successful in 51s

Details

Intégration / Tests unitaires et couverture (pull_request) Successful in 59s

Details

Intégration / Dépendances du tableau de bord (pull_request) Successful in 11s

Details

Intégration / Images épinglées par version (pull_request) Successful in 3s

Details

Intégration / Tableau de bord (pull_request) Successful in 23s

Details

Intégration / Aucun secret commité (pull_request) Successful in 3s

Details

Intégration / Dépendances Python et inventaire applicatif (pull_request) Successful in 1m38s

Details

ee28bbb37e

MLflow était épinglé à 3.15.2, ses dépendances indirectes ne l'étaient pas. Le
3 septembre à 17 h 08, la reconstruction déclenchée par la mise en production a
tiré anyio 4.15.0, passé aux imports paresseux, qui n'expose plus from_thread en
attribut. starlette 1.6.0 l'appelle après un simple « import anyio » : le serveur
démarrait, répondait 500, et restait unhealthy — ce qui a fait échouer le
déploiement, wait: true attendant une pile saine.

L'image tournait « Up 21 hours (healthy) » le matin même avec les mêmes fichiers.
Seules les versions indirectes avaient changé, et c'est précisément ce que le
commentaire en tête du fichier voulait empêcher.

Vérifié dans un conteneur jetable avant de pousser : avec « anyio<4.15 », pip
résout 4.14.2, from_thread redevient accessible et starlette.middleware.wsgi
s'importe.

Reste à trancher, et c'est le #130 : la pile mlflow porte build: true, donc son
image est reconstruite à CHAQUE déploiement. postgres aussi. Épingler ferme ce
trou-ci, pas la classe entière.