The data deletion endpoint is returning a 409 Conflict error when multiple Subject Access Requests are submitted concurrently for the same data subject. This impacts our ability to comply with GDPR Article 17, specifically the ‘right to erasure’ without undue delay. It appears the system is not handling parallel processing of deletion requests effectively.
We’ve observed this consistently when initiating data deletion workflows through Architect flows (v2.6) which invoke the /api/v2/data-deletions POST request. The Architect flow first validates consent via a custom data action, ensuring the request aligns with documented consent records. Then, it constructs the payload. The error consistently appears after the POST request is sent.
The error response body is as follows:
{
"message": "Conflict: A deletion request is already in progress for this data subject.",
"code": 409,
"details": {
"error_code": "DATA_DELETION_CONCURRENT_REQUEST"
}
}
This suggests a locking mechanism is in place, however, the timeout period appears insufficient given typical request volumes. We’ve reviewed previous community posts regarding data deletion functionality, though none address the specific scenario of concurrent requests triggering a 409.
The system is configured to retain deletion logs for audit purposes, as required by GDPR Article 13. The logs confirm the initial request is processed successfully, but subsequent concurrent requests are blocked. This creates a potential compliance risk, as complete erasure is not guaranteed within a reasonable timeframe.
Here’s a summary of the environment and steps taken:
- Region: Frankfurt (EU17)
- API Version: v2
- Architect Flow Version: 2.6
- SDK Version (Node.js): 16.13.0
- Data Action: Custom data action validating GDPR consent records prior to deletion initiation.
- Test Procedure: Multiple simultaneous data deletion requests initiated via a test script simulating concurrent SAR submissions.
- Workaround Attempted: Implementing request queuing within the Architect flow, but this significantly increased processing time and introduced unacceptable delays.
The current configuration does not seem to allow for adequate handling of concurrent Article 17 requests. A more solid concurrency management strategy is required to ensure adherence to GDPR regulations. It’s also worth noting, the error message could benefit from more descriptive detail regarding the potential delay before a retry attempt is viable.