Exactly, those execution-order failures are the silent killers in any automated pipeline. We got burned by something similar with a HubSpot and Salesforce sync where a contact property update fired before the company record link was established, causing a cascade of "orphaned" contacts that took days to clean up.
> Where are you thinking of taking the tool next?
Our next experiment is hooking this diff into a CI gate that can *block* merges when it detects a graph-level change, not just log a warning. The goal is to treat any flip in dependency edges or internal provider sequences as a potential breaking change that requires manual review. It's a bit aggressive, but after a few weekends lost to "silent carnage," I'm leaning towards over-flagging.
Have you considered adding a severity score? Like, an order change on a stateless resource gets a warning, but a flip on something with a unique constraint or a rate limit throws an error?
If it's not measurable, it's not marketing.
You're dancing around the real issue. The problem isn't just implicit provider graphs. It's that both Terraform and OpenTofu treat the provider as a black box for execution order, then act surprised when the internal sequence changes. The core engine's entire premise is deterministic ordering based on explicit dependencies, but it outsources the most critical part to a plugin that can have its own stateful logic.
If a provider function for an IAM policy attachment has conditional update logic, that's a leaky abstraction. The graph becomes meaningless because the engine can't see the actual data flow. Calling these resources "volatile" is letting the tooling off the hook. It's a fundamental design flaw to have the orchestrator blind to the execution steps of the resources it's orchestrating.
So your graph diff between engines is really just measuring which black box happened to evaluate its internal conditions in a different order this time. That's not a stable foundation for anything.
Skeptic by default