Skip to content

feat(api): initialize FastAPI with uvicorn logging and CORS middleware#31

Open
Kaiohz wants to merge 2 commits into
mainfrom
feat/add-tesseract-option
Open

feat(api): initialize FastAPI with uvicorn logging and CORS middleware#31
Kaiohz wants to merge 2 commits into
mainfrom
feat/add-tesseract-option

Conversation

@Kaiohz
Copy link
Copy Markdown
Collaborator

@Kaiohz Kaiohz commented May 6, 2026

Configure uvicorn access log integration, add CORS middleware setup, and implement health check endpoint with proper logging configuration. Set default log level to INFO and prepare alembic migration runner utility.

Kaiohz added 2 commits May 6, 2026 16:55
Configure uvicorn access log integration, add CORS middleware setup, and
implement health check endpoint with proper logging configuration. Set
default log level to INFO and prepare alembic migration runner utility.
Copy link
Copy Markdown
Collaborator Author

@Kaiohz Kaiohz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Code Review

📊 Score: 6/10

La simplification est louable, mais l'implémentation a des problèmes potentiels.


✅ Points positifs

  • Simplification du code (moins verbeux)
  • force=True permet de reconfigurer le logging proprement
  • stdout est plus standard pour les containers (Docker/K8s)
  • Le format reste cohérent et lisible

⚠️ Problèmes identifiés

1. Perte du contrôle sur les loggers uvicorn

La config précédente configurait explicitement :

"loggers": {
    "uvicorn": {...},
    "uvicorn.error": {...},
    "uvicorn.access": {...},
}

Avec basicConfig, ces loggers n'ont plus de config spécifique. Uvicorn risque d'utiliser son propre handler par défaut, ce qui peut causer :

  • Format de log différent pour les logs uvicorn
  • Perte de contrôle sur le niveau de log des access logs

2. log_config=None peut causer des doublons

En passant None à uvicorn, il utilise sa config par défaut. Comme tu as déjà appelé basicConfig() avant, il y a un risque de double logging :

  • Tes logs via basicConfig
  • Les logs uvicorn via sa config interne

3. Import asyncio non utilisé

import asyncio  # <-- ajouté mais jamais utilisé

4. Suppression du module docstring

Le docstring """Main entry point for the RAGAnything API.""" a été retiré. Ce n'est pas bloquant, mais ça réduit la clarté du module.


💡 Suggestions d'amélioration

Option A: Utiliser la config native uvicorn

# Pas de basicConfig(), laisser uvicorn gérer
uvicorn.run(
    app,
    host=app_config.HOST,
    port=app_config.PORT,
    log_level=app_config.UVICORN_LOG_LEVEL,
    access_log=True,
)

Option B: Garder une config structurée (recommandé)

LOGGING_CONFIG = {
    "version": 1,
    "disable_existing_loggers": False,
    "formatters": {
        "default": {
            "format": "%(asctime)s - %(name)s - %(levelname)s - %(message)s"
        },
    },
    "handlers": {
        "stdout": {
            "class": "logging.StreamHandler",
            "formatter": "default",
            "stream": "ext://sys.stdout",
        },
    },
    "root": {"level": "INFO", "handlers": ["stdout"]},
}

logging.config.dictConfig(LOGGING_CONFIG)

Et passer cette config à uvicorn :

uvicorn.run(..., log_config=LOGGING_CONFIG)

❓ Questions

  1. Quelle était la motivation principale de cette simplification ?
  2. As-tu testé que les logs uvicorn (access logs en particulier) sortent correctement ?
  3. Y'a-t-il une raison pour retirer le module docstring ?

En l'état, je recommanderais de revoir la gestion du logging pour éviter les problèmes de double logging et perte de contrôle sur les logs uvicorn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant