Open jeohist opened 8 months ago
It seems like the provider is attempting to delete the Space too quickly for the API to catch up.
If you're suspecting eventual consistency, it's definitely not that - these operations are all transactional, unless there's a stack destructor involved (which defers the stack deletion), which does not seem to be the case here.
It's unclear to me why Terraform/OpenTofu would try to delete a space before it deletes all the stacks that belong to that space. My understanding is that this has something to do with how it sees and executes these dependencies. Perhaps the funky way in which they're defined makes the dependency resolver confused?
The part showing the ordering of calls (start time and finish time) would be most interesting here, to understand if Terraform/OpenTofu has been messing up with the ordering.
I am writing tests for a module which creates several
spacelift_space
containingspacelift_stack
. During the destroy phase, these tests will almost always fail with the following error:It seems like the provider is attempting to delete the Space too quickly for the API to catch up. From the error message you can see it has partially succeeded, and locally a second
terraform destroy
succeeds. Since this is happening in module testing, it means I have to clean it up by myself. I can't work around it either withtime_sleep
because it would create a cyclic dependency.Here's some reproduction code:
Here's the relevant part of the debug logs: