Idempotency Issue: Concurrent Requests Before Document Ingestion / Response Completion
Description
There is an idempotency and request-ordering issue in the current system flow.
When a user requests to add a document, the system still allows:
- Sending chat/messages before the document is fully added
- Sending multiple messages concurrently without waiting for the response of the previous request
This can lead to:
- Inconsistent RAG context
- Duplicate or invalid requests
- Responses generated without the required document being available
- Race conditions in backend processing
This should be handled through the WebSocket session to ensure proper session-level sequencing.
Current Behavior
- User requests to add a document
- System accepts additional messages before document ingestion is completed
- User can send another message before receiving the response to the previous one
- Requests may be processed out of order
Expected Behavior
The system should enforce strict sequential processing per WebSocket session:
Document Ingestion Lock
- Once a document add request is initiated, block all chat/message requests on the same WebSocket session
- Allow messages only after document ingestion completes successfully
Message Request Lock (Idempotency)
- Prevent sending another message until the response to the previous message is received
- Ensure only one in-flight request at a time per WebSocket session
Importance
- Ensures idempotent behavior
- Prevents duplicate or overlapping requests
- Guarantees responses are generated using the correct document context
- Maintains WebSocket session consistency
- Improves system reliability and user experience
Suggested Solutions
- Introduce a session-level request state flag (e.g.,
isProcessing)
- Use backend request locking or queueing per WebSocket session
- Return an error (e.g., 409 Conflict or 429 Too Many Requests) if a request is already in progress
- Disable frontend input while document ingestion is running or a message response is pending
Idempotency Issue: Concurrent Requests Before Document Ingestion / Response Completion
Description
There is an idempotency and request-ordering issue in the current system flow.
When a user requests to add a document, the system still allows:
This can lead to:
This should be handled through the WebSocket session to ensure proper session-level sequencing.
Current Behavior
Expected Behavior
The system should enforce strict sequential processing per WebSocket session:
Document Ingestion Lock
Message Request Lock (Idempotency)
Importance
Suggested Solutions
isProcessing)