Commit Graph

4 Commits

Author SHA1 Message Date
Fraser Waters a3128e50be Do not execute pending deletes at the start of deployment
This removes all the handling of pending deletes from the start of
deployments. Instead we allow resources to just be deleted as they
usually would at the end of the deployment.

There's a big comment in TestPendingDeleteOrder that explains the order
of operations in a succesful run and how that order differs if we try
and do pending deletes up-front.

Fixes https://github.com/pulumi/pulumi/issues/2948
2022-10-14 15:52:13 +01:00
Sean Gillespie a35aba137b
Retire pending deletions at start of plan ()
* Retire pending deletions at start of plan

Instead of letting pending deletions pile up to be retired at the end of
a plan, this commit eagerly disposes of any pending deletions that were
pending at the end of the previous plan. This is a nice usability win
and also reclaims an invariant that at most one resource with a given
URN is live and at most one is pending deletion at any point in time.

* Rebase against master

* Fix a test issue arising from shared snapshots

* CR feedback

* plan -> replacement

* Use ephemeral statuses to communicate deletions
2018-09-10 16:48:14 -07:00
Sean Gillespie a09d9ba035
Default to a parallelism fanout of 10 ()
* Default to a parallelism fanout of 10

* Add dependsOn to double_pending_delete tests to force serialization
2018-08-10 14:16:59 -07:00
Sean Gillespie 57ae7289f3
Work around a potentially bad assert in the engine ()
* Work around a potentially bad assert in the engine

The engine asserts if presented with a plan that deletes the same URN
more than once. This has been empirically proven to be possible, so I am
removing the assert.

* CR: Add log for multiple pending-delete deletes
2018-07-18 15:48:55 -07:00