engine/planning: A note about provider handling in this design

This is a problem that has been on my mind for the past little while as
I've been building this out, so I just wanted to write it down in a place
where others reading this code could find it, to acknowledge that there is
a gap in this new design idea that prevents it from having the similar
provider open/close behavior to the current implementation.

Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This commit is contained in:
Martin Atkins
2025-09-12 12:53:03 -07:00
parent 5d3f51c56a
commit 1ffe07f54a

View File

@@ -64,6 +64,21 @@ func PlanChanges(ctx context.Context, prevRoundState *states.State, configInst *
// instances remain. The second sub-phase also uses provider instance
// configuration and ephemeral resource instance configuration provided
// by lang/eval through the return value of the first phase.
//
// Note that this approach implies that any provider instance that is
// associated with a resource instance in prevRoundState and which
// gets used during subphase 1 must always be kept open through the
// remainder of subphase 1 _just in case_ any of the resource instances
// that refer to it turn out to be "orphans". In turn that means that
// any ephemeral resource instances that any of those provider instances
// rely on must also remain open, and in turn the provider instances that
// those ephemeral resource instances belong to. So we would probably end
// up keeping most of the provider instances open throughout anyway and
// so maybe it's not worth the complexity of trying to calculate when it's
// okay to close them. If we _do_ want to still track this precisely then
// we'll need to extend the PlanGlue API to include additional announcements
// about what's present in the configuration so that the orphan planning
// can happen concurrently with the desired state planning.
planCtx := newPlanContext(configInst.EvalContext(), prevRoundState)