Are delete lifecycle operations always leaf nodes in the graph? It seems that way. I haven't been able to get anything to run AFTER a delete, or to depend on the outcome of a delete operation.

I haven't played with them yet, but theoretically there are resource hooks for after delete - https://www.pulumi.com/docs/iac/concepts/options/hooks/

That's what I've been using, but my situation is a little different:

ComponentResource(A)
   - Resource(B)
   - Resource(C)

If the after_delete hook is applied to ComponentResource(A), they are not called if Resource(C) is deleted. That seems reasonable. If an after_update hooks is applied to ComponentResource(A), and Resource(C) is deleted but that deletion changes the state of ComponentResource(A) such that it registers as an update (difference in inputs), the after_update hook is called, but only after the delete of Resource(C). That's a fine design decision I suppose, but I'm running into problems because of how Pulumi treats deleted objects, even before they are actually deleted, as non-entities. They have no rights and nothing waits for them to be deleted.

Ohhh, very interesting. Apologies, I've only started looking at these (just found out they existed), so I haven't gone into that kind of depth on the scenarios yet. So essentially, in the case of resource C being deleted, you want the following sequence of events - C is deleted, a particular piece of code for this circumstance is run, and then A is updated?

Yeah that's exactly right. What we ended up doing to control this behavior is place Resource C into a component resource with another new resource called Controller(C) (hypothetically), which takes the ID of all instances of Resource(C)'s and handles the state management of deleted resources as an update.

Is a before_delete hook not early enough? You might be hitting the issue that pulumi schedules all deletes at the end of the program (because its at that point that we can see no more resource registrations are coming in, and so everything left over can be deleted).

I talked more about the structure of my program here @echoing-dinner-19531 https://pulumi-community.slack.com/archives/CDE799L1M/p1758641715161229?thread_ts=1758318336.853679&cid=CDE799L1M You're definitely describing what we're running into. The scheduling of deletes at the end of the program left us unable to respond to delete operations the way we expected. A before_delete hook doesn't work because the outcome of the delete needs to be represented in the state in our case.