Skip to content

Refactor the draft creation process to fix 400 Bad Request errors.

Edouard Legoupil requested to merge fix-draft-creation-flow into main_dev

Created by: Edouard-Legoupil

The previous implementation for creating a new proposal draft was convoluted, involving two separate API calls (/store_base_data and /save-draft) and a race condition in the frontend. This complex and buggy flow led to inconsistencies in the application state, resulting in 400 Bad Request errors when processing proposal sections.

This commit refactors the draft creation process by:

  1. Simplifying the backend: The /save-draft endpoint in backend/api/proposals.py no longer requires a session_id to create a new draft. It now takes all necessary data from the request body, making it a single, self-contained endpoint for creating and updating drafts.

  2. Streamlining the frontend: In frontend/src/screens/Chat/Chat.jsx, the handleGenerateClick function has been refactored to remove the call to the redundant /store_base_data endpoint. It now directly calls /save-draft to create the proposal and then calls getContent to load the newly created draft, which correctly establishes a valid session for subsequent operations.

This new, simplified flow is more robust, eliminates the race condition, and ensures the application state is managed correctly, thereby resolving the 400 Bad Request errors.

  • 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