Martin Atkins ac9a26d5b9 exec: ManagedDepose and ManagedChangeAddr take object as operand ...

These both effectively had the behavior of ResourceInstancePrior embedded
in them, reading something from the state and change its address as a
single compound operation.

In the case of ManagedDepose we need to split these up for the
CreateThenDestroy variant of "replace", because we want to make sure the
final plans are valid before we depose anything and we need the prior state
to produce the final plan. (Actually using that will follow in a subsequent
commit.)

This isn't actually necessary for ManageChangeAddr, but splitting it keeps
these two operations consistent in how they interact with the rest of the
operations.

Due to how the existing states.SyncState works we're not actually making
good use of the data flow of these objects right now, but in a future world
where we're no longer using the old state models hopefully the state API
will switch to an approach that's more aligned with how the execgraph
operations are modeled.

Signed-off-by: Martin Atkins <mart@degeneration.co.uk>

2026-02-10 07:07:01 -08:00

..

apply.go

engine/applying: Track grapheval/workgraph requests

2026-02-02 10:27:07 -08:00

operations_provider.go

engine/applying: Use "apply phase" prefix in trace logs

2026-02-02 10:27:07 -08:00

operations_resource_data.go

engine/applying: Use "apply phase" prefix in trace logs

2026-02-02 10:27:07 -08:00

operations_resource_ephemeral.go

engine/ephemeral: Wire together basic ephemeral functionality (#3710)

2026-02-04 16:44:20 -05:00

operations_resource_managed.go

exec: ManagedDepose and ManagedChangeAddr take object as operand

2026-02-10 07:07:01 -08:00

operations_resource.go

engine/applying: Use "apply phase" prefix in trace logs

2026-02-02 10:27:07 -08:00

operations.go

engine/applying: Track grapheval/workgraph requests

2026-02-02 10:27:07 -08:00

request_tracker.go

engine/applying: Track grapheval/workgraph requests

2026-02-02 10:27:07 -08:00