--simulate reflects agent state, not actual AWS state — plan output is unreliable after drift

[techcooldude]

Summary

formae apply --simulate (the "plan" equivalent) compares desired state against the agent's internal memory, not against actual AWS resource state. This means the plan output can say "No changes" while a subsequent real apply creates, replaces, or deletes resources.

Steps to Reproduce

1. Deploy a stack successfully (e.g. EC2 instance + security group + Elastic IP).
2. Manually delete one or more resources from the AWS console (or restart the Formae agent, clearing its state).
3. Run formae apply --mode reconcile --simulate --yes --watch against the same PKL config.
4. Observe: simulate reports "No changes. Infrastructure is up-to-date."
5. Run formae apply --mode reconcile --yes --watch (real apply).
6. Observe: apply creates the missing resources — contradicting the plan.

Expected Behavior

--simulate should perform a live AWS API check (describe/list) to compare desired state against actual infrastructure, then report what would change — similar to how terraform plan refreshes state before diffing.

Actual Behavior

--simulate trusts the agent's last known state. Any drift between agent state and real AWS (manual changes, agent restart, out-of-band deletions) results in a plan that says "no changes" while apply makes real changes.

Impact

• CI/CD pipelines with a plan → apply gate give a false sense of safety — the plan approval is meaningless if it can't detect drift.
• Users cannot trust plan output as a preview of what apply will do.

Environment

• Formae version: 0.83.2
• AWS provider: v0.1.4
• Deployment: Docker agent (ghcr.io/platform-engineering-labs/formae:0.83.2) on EC2

[JeroenSoeters]

Hey @techcooldude, you are right that simulate runs against the agent's view of the infrastructure. This is not stored in memory though but in the DB that is configured (default SQLite but can be Postgres, Aurora or MSSQL). The agent keeps this state in sync with reality by means of discovery (of new resources created out-of-band) and synchronization (of resources it already knows of). This leaves of course open a window when a change is made OOB and you run an apply before the next synchronization cycle has kicked in. This is why every update during an apply does an extra check whether the resource is still in the state the agent expected it to be. If not, the new cloud state is absorbed in the agent but the actual update will be rejected. This way there is never a risk of accidentally overwriting someone else's changes. Agent restarts do not affect this behavior as all state is stored in the DB. Hope this makes sense?

PS: you are running a pretty old version of formae and the AWS plugin, I'd recommend updating to the latest (0.86.0 and 0.1.11).