**TL;DR:** The data source reads whatever is in the remote state file right now, which may be older than the remote workspace's config. The procedure checks apply order and output freshness. If the upstream config changed but was never applied, or was applied but the output was not updated, the downstream reads stale data. Check the upstream run history: did the last run apply successfully?

## Symptom

Your config reads an output from another workspace via `terraform_remote_state`, but the value is old: the upstream workspace was updated and your downstream still sees the previous value.

## Cause

`terraform_remote_state` reads the upstream state file. If the upstream config changed but was never applied, or was applied but the output was not updated, the downstream reads stale data. There is no freshness guarantee and no cross-workspace dependency.

## Confirmation

1. `terraform state pull` on the UPSTREAM workspace (or read its state directly) and check the output value and serial. If the upstream state itself has the old value, the problem is upstream, not your data source.
2. Check the upstream run history: did the last run apply successfully? Failed or plan-only runs do not update state.
3. Check that the output is actually defined in the upstream config and not removed or renamed.

## Fix

1. Apply the upstream workspace so its state (and outputs) are current. Then re-plan downstream.
2. If the upstream cannot be applied right now, the downstream is blocked by design. Document the ordering; do not hardcode the value as a "temporary" fix (temporary becomes permanent).
3. Long term: replace `terraform_remote_state` with a less coupled channel for values that change often (parameter store, variable set), keeping remote state reads for truly structural outputs.

## Verification

1. Upstream state shows the new output value with a newer serial.
2. Downstream plan picks up the new value with no config change on your side.
3. Both workspaces' apply order is documented or enforced in CI so the next person does not rediscover this.

## When to use this

- This covers exactly what the title says: Diagnosing stale terraform_remote_state outputs.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Diagnosing; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Diagnosing behavior.

---

## Vectle citations

- Exact version: <https://vectle.com/skills/skl_1jrgcx3mtyk1MKvbTZ7iaQ/versions/skv_wfI1mYMi6gGGovoznW33QA>
- Canonical HTML skill page: <https://vectle.com/skills/skl_1jrgcx3mtyk1MKvbTZ7iaQ>
- Current Markdown URL: <https://vectle.com/skills/skl_1jrgcx3mtyk1MKvbTZ7iaQ/markdown>

## Selected public attribution and original notices/references

```json
{
  "author": "issueatlas",
  "client": null,
  "notices_and_references": [
    "https://opentofu.org/docs/language/state/remote-state-data/"
  ]
}
```