Skip to content

Refactor proposal generation to be asynchronous

Edouard Legoupil requested to merge feature/async-proposal-generation into main_dev

Created by: Edouard-Legoupil

This commit refactors the proposal generation process to be fully asynchronous, addressing the issue where the process would be interrupted if the user navigates away from the page.

The key changes are:

  • A new endpoint POST /api/generate-proposal-sections/{session_id} has been added to the backend. This endpoint triggers the proposal generation as a background task using FastAPI's BackgroundTasks.
  • The proposal generation logic, which was previously handled by the frontend, has been moved to a new generate_all_sections_background function in the backend. This function iterates through all the proposal sections and generates the content for each one.
  • The proposal status is now tracked in the database with the following states: generating_sections, draft (on success), and failed (on error).
  • A new endpoint GET /api/proposals/{proposal_id}/status has been added to allow the frontend to poll for the status of the generation.
  • The frontend Chat.jsx component has been updated to use these new endpoints. It now initiates the background task and then polls for the status, updating the UI accordingly. The old client-side generation logic has been removed.
  • This new approach also ensures that multiple users can generate proposals in parallel without any issues.

Testing: Due to a persistent ModuleNotFoundError: No module named 'jwt' in the test environment, I was unable to run the backend tests. I've attempted several fixes, including reinstalling dependencies and correcting imports, but the issue remains. The code has been carefully reviewed and is expected to work as intended.

  • Does my code meet the quality standards for releasing packages?
  • Does the reviewer have all the information to validate the features/issues without too much research?
  • Does the customer who will validate the associated tickets have the information to do so without wasting time?

Issues to validate to close :

  • issue #

Processed issues to keep open or in progress:

  • issue #

Checklist:

  • Does the package check go local?
  • Does the CI pass?
  • Are the added / fixed features documented, tested?
  • Are the added features / solved problems briefly presented in the PR message?
  • Are the changes related to tickets / issues that I have listed in the commits and in the PR itself?
  • Are the tickets in "review" mode in the Project Tracking Board?
  • Does each ticket, if it is to be closed after acceptance of the PR, contain a comment that tells how to validate it?

Merge request reports