v2.0.1

🐛 Bug Fixes

fix(remote-state): use state format v4 for dummy remote state (OpenTofu 1.13) Erik Osterman (Cloud Posse) (@osterman) (#113)

## what

• Replace modules/remote-state/dummy-remote-state.json ({"version": 1}) with an empty state format v4 document (version: 4, terraform_version: "0.12.0", empty outputs/resources).

why

• OpenTofu 1.13.0 removed the legacy v0–v3 state readers (opentofu/opentofu#4228). statefile.Read now accepts only version: 4.

• When a component's backend is none/static, or it can't be resolved (for example with ignore_errors), remote-state points terraform_remote_state at this stub through the local backend. On OpenTofu ≥1.13 every such lookup fails:

  Error: Unsupported state file format
  The state file uses format version 1, which is not supported by OpenTofu 1.13.1.
  This state file may have been created by a newer version of OpenTofu.
  

• v4 is readable by Terraform ≥0.12 and by every OpenTofu release, so one stub supports old and new versions with no version detection. terraform_version is pinned low (0.12.0) because Terraform 0.12–0.14 refuse state written by a newer CLI version.

• Behavior is unchanged otherwise. The stub still has no outputs, so remote-state still falls back to defaults / bypass.

Verification

examples/remote-state (the terratest fixture, which already exercises this fallback) run locally:

Engine	Before	After
OpenTofu 1.13.1	❌ Unsupported state file format (3 modules)	✅ outputs match examples_remote_state_test.go assertions
OpenTofu 1.12.6	✅	✅
Terraform 1.15.6	✅	✅

Minimal terraform_remote_state + v4 stub also verified on Terraform 1.0.11 and 0.13.7.

references

• cloudposse/atmos#3282
• cloudposse-terraform-components/.github#186 (temporary tofu_version: 1.12.6 pin, which can be reverted once this ships)
• A backport to release/v1 follows in a separate PR.

🤖 Generated with Claude Code