Skip to content

fix: Correct proposal section loading and improve validation

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

Created by: Edouard-Legoupil

This commit 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. It no longer loads a default list of sections on mount. Instead, after a user selects a template and clicks "Generate", it fetches the correct sections for that specific template.
  • Improved State Management: A useEffect hook has been added to reliably trigger the section generation process only after the correct sections have been fetched and the component's state has been updated, preventing race conditions.
  • Bug Fix in getContent: A bug that caused an error when populating the proposal state from a loaded draft has been fixed.

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