Implémentation de RabbitMQ #406
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| revision: str = "788a3b052a11" | ||
| down_revision: Union[str, None] = "c1e54102255e" | ||
|
|
||
| revision: str = '479aeeae940b' |
Check notice
Code scanning / CodeQL
Unused global variable Note
| down_revision: Union[str, None] = "c1e54102255e" | ||
|
|
||
| revision: str = '479aeeae940b' | ||
| down_revision: Union[str, None] = '788a3b052a11' |
Check notice
Code scanning / CodeQL
Unused global variable Note
app/endpoints/models.py
Outdated
| raise HTTPException(status_code=404, detail=f"Model '{model}' not found") | ||
|
|
||
| model = models[0] | ||
| model = await global_context.model_registry.list(model=model)[0] |
There was a problem hiding this comment.
Pourquoi avoir supprimé la gestion d'erreur si le model n'est pas trouvé ? On va se retrouver avec un IndexError alors qu'on avait une erreur explicite initialement.
There was a problem hiding this comment.
je pense pas avoir fait exprès, j'ai remis
| @@ -1,6 +1,6 @@ | |||
| import json | |||
| from types import SimpleNamespace | |||
| from unittest.mock import AsyncMock | |||
| from unittest.mock import AsyncMock, MagicMock | |||
Check notice
Code scanning / CodeQL
Unused import Note test
There was a problem hiding this comment.
J'ai testé le code localement, et voici mes remarques :
- Problème : les exceptions côté consumer (ex.
WrongModelTypeException) se perdent dans le chemin RabbitMQ et apparaissent comme des timeouts côté appelant. - Correctif immédiat : dans
_dispatch, catcher les erreurs, renvoyer l'exception vers leWorkingContext(p.ex.ctx.send_result(e)) et ack le message pour éviter qu'il soit re-queued :
except Exception as e:
ctx.send_result(e)
await message.ack()- Architecture : éviter les
if configuration.dependencies.rabbitmqau cœur deModelRegistry. Préférer une interface/abstraction (ex.ModelRegistryBase) et deux implémentations claires :ModelRegistrySync(sans queue) etModelRegistryQueue(RabbitMQ). Cela rend le code plus testable et lisible. - Tests : ajouter des tests unitaires et d’intégration pour les deux modes (sync/queue). Plusieurs tests actuels échouent quand RabbitMQ est activé — couvrir explicitement la propagation d’erreur et le nettoyage des contexts.
- Proposition long-terme : envisager Celery (https://docs.celeryq.dev/) au lieu d’un wiring RabbitMQ fait maison. Celery supporte plusieurs brokers (Redis ou RabbitMQ), backend de résultats, retries, et simplifie le choix du broker (on pourrait utiliser Redis en dev/CI et éviter d’ajouter une image RabbitMQ).
- Ajouter des tests unitaires/intégrations (ça sera également plus simple à faire avec Celery)
Reprise de la PR #376, mise à jour sur main (29/08/25)