TL;DR: Terragrunt evaluates an included `remote_state` block before dependency outputs exist, so a shared remote_state that references `dependency.*` prints `Error: Unknown variable` even though the run succeeds. Stop referencing `dependency` inside shared remote_state blocks; build the state key from locals or static values instead.

```text
ERROR Error: Unknown variable
ERROR   on /tmp/tg-repro/_shared/remote_state.hcl line 8, in remote_state:
ERROR    8:     path = "${dependency.sub.outputs.id}-${dependency.rgs.outputs.name}.tfstate"
ERROR There is no variable named "dependency".
```

(The run then completes with `EXIT=0`; the errors are noise from partial-parse passes.)

## Steps

1. Confirm the errors are the spurious kind: the run exits 0 and the real `terraform` output (e.g. `No changes`) appears after them.
   Expected: plan/apply output is present and correct.
2. Find the `dependency.*` reference inside the included `remote_state` block.
   Expected: something like `path = "${dependency.x.outputs.y}-..."` in a shared file.
3. Rewrite the key without dependency outputs: use `path_relative_to_include()`, a static naming convention, or a local read from a config file.
   Expected: no `dependency.` references remain in any included `remote_state` block.
4. Re-run the same command.
   Expected: the `Unknown variable` errors are gone.

## When this applies

- `terragrunt plan` prints `Error: Unknown variable` / `There is no variable named "dependency"` pointing at a shared `remote_state` file, but exits 0.
- The reference is inside an `include`d config, not the unit's own file.

## When it doesn't apply

- A genuinely missing `dependency "name"` block in the unit: then the error is real and the fix is to add the block.
- `Error: Unsupported attribute` on `dependency.x.outputs.y`: that's a missing output or unapplied dependency, different fix (`mock_outputs`).

## Tool versions

Terragrunt 1.x (reported on recent 1.1.x).

## Why it happens

Terragrunt parses included configs in multiple passes. During an early pass triggered while resolving the unit's own `dependency` blocks, the included `remote_state` is evaluated before any dependency outputs exist, so `dependency` is unbound and each evaluation prints the error. Later passes succeed, which is why the exit code stays 0.

## Edge cases

- If you truly need a dynamic state key per dependency, compute it in the unit's own `locals` (where `dependency` is in scope at the right stage) and pass it into the shared file via `expose`, rather than referencing `dependency` inside the shared file directly.