Unused FastAPI dead code in backend/main.py

[vedant-kawale-27]

Title: Unused/dead FastAPI implementation in backend/main.py and schema dependencies

Description: The repository has a FastAPI server (main.py) which exposes /api/emails endpoints for MySQL storage. However, the application uses Flask (api.py) in production, docker-compose, and the local developer orchestrator. The FastAPI system and its dependencies (database.py, emails.py, export.py) are dead code.

Steps to Reproduce:

Inspect the running services in docker-compose.yml or run-dev.ps1; they exclusively launch api.py.
Proposed Fix: Either clean up the repository by removing main.py, database.py, emails.py, and export.py, or fully integrate the email database system into the active Flask service.

[github-actions]

👋 Welcome back! Thanks for your continued contribution. Your issue/PR is received and waiting for maintainer review.

[github-actions]

The text discusses two separate issues. The first highlights unused FastAPI code and dependencies in a project where Flask is used in production, suggesting either removing the unused code or fully integrating it into the Flask system. The second issue notes that the "confidence" field is missing when saving query predictions to the history database in a MongoDB schema and proposes updating the relevant server route to include this field.

[Userunknown84]

Main.py is only for the flask route and it has no relation with api.py and docker. That code is just for flask. You can work on confidence score to save in mongodb.

[vedant-kawale-27]

Regarding main.py: Actually, it is the other way around:
api.py is the Flask server that our Docker/development environment currently runs.
main.py is a FastAPI server (using from fastapi import FastAPI), which is currently not used or referenced anywhere in docker-compose.yml or run-dev.ps1.
We should probably clean up main.py, database.py, emails.py, and export.py in the future to keep the repository clean, as they are unused FastAPI/SQL dependencies.
Regarding the MongoDB Confidence Score:
This is already fully implemented.
In

backend/server.js
, the /predict route already maps and persists the score: confidence: response.data.confidence.
The MongoDB schema in

backend/models/History.js
also properly defines the confidence field as a Number.

[Userunknown84]

We can do is kept this code in separate folder so this code has a separate folder to run , test the functionality.