MongoByte
Welcome to the new MongoDB Feedback Portal!
{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.
Welcome to the new MongoDB Feedback Portal!
{Improvement: "Your idea"}
We’ve upgraded our system to better capture and act on your feedback.
Your feedback is meaningful and helps us build better products.
|
What problem are you trying to solve? Focus on the what and why of the need you have, not the how you'd like it solved. |
When an Atlas project configures backup snapshot exports to S3 via the Backup API and manages those settings through Terraform (and other IaC tools), attempts to delete the configuration via the API can fail with a 400 Bad Request because the export bucket remains referenced by auto export settings even after a successful |
|
What would you like to see happen? Describe the desired outcome or enhancement. |
Provide API support to clean up auto export. |
|
Why is this important to you or your team? Explain how the request adds value or solves a business need. |
This leads to inconsistent behavior for API consumers and forces a manual workaround in automation tools (i.e. retry logic, 2 step processes, etc). |
What steps, if any, are you taking today to manage this problem? |
0
Future Consideration
Thank you for the detailed feedback and for explaining your IaC/Terraform use case - this is really helpful context for us.
Today, the Remove Backup Schedule API only removes the snapshot schedule policies. It does not clear
copySettingsorautoExportSettings, which is why you can still see 400 responses when the export bucket remains referenced by auto exports even after a successful schedule delete. The current workaround is to handle this as a two-step process in automation (delete the schedule, then separately adjust or remove the export configuration).We agree that having first-class API support to clean up these export settings would make Terraform and other IaC workflows more reliable and less error-prone. We’re exploring an additive change: for example, introducing an optional query parameter on the delete endpoint that, when set to
true, would also clear the associated copy/auto export settings while preserving the existing behavior by default for other users.Given current priorities and the availability of a workaround, this improvement is being targeted for our longer-term roadmap rather than near-term work. We’ve captured this request and will update this item once we have a more concrete timeline to share.