Skip to content

fix: Refactor proposal generation flow and add validation

Edouard Legoupil requested to merge fix/template-loading-error-handling into main_dev

Created by: Edouard-Legoupil

This is a comprehensive fix that addresses a multi-faceted bug that caused proposal section generation to fail. The fix involves changes to both the frontend and backend.

Backend Changes:

  • Strict UUID Validation: The proposal_id in all relevant Pydantic models (schemas.py) and API endpoints (proposals.py) is now enforced as a uuid.UUID type. This prevents invalid strings (e.g., "undefined") from being processed and causing database errors.
  • Robust Error Handling: The proposals API now has improved try...except blocks to catch database and other exceptions, with better logging for easier debugging.
  • load_draft Fix: The /load-draft endpoint now correctly includes the proposal_id in its response, which was a source of the "undefined" proposal_id issue on the frontend.

Frontend Changes:

  • Correct Section Loading: The frontend logic in Chat.jsx has been refactored. The handleGenerateClick function now follows a robust save-then-load pattern. It first saves the draft (with the user-selected template), then immediately re-loads that draft to get a fresh session from the backend that contains the correct proposal structure.
  • Improved State Management: This new flow ensures the proposal state on the frontend is always correctly initialized with the sections corresponding to the chosen template before the generation process begins, fixing a critical race condition.

These changes together ensure that the correct proposal sections are always used for generation and that the backend is resilient to invalid data.

  • 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