cloudposse / cloudposse/atmos

atmos terraform plan/apply reports raw filesystem path as component identity for path-style args

Open
#3,110 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
1.4k
Forks
175
Avg merge
2d 3h
Merged PRs (30d)
134

Description

## Description

When a `terraform` component is invoked with a path-style CLI argument (e.g. `atmos terraform plan ./components/terraform/vpc`), the single-component exec-metadata execution record reports the raw filesystem path (`./components/terraform/vpc`) as the component identity instead of the resolved logical component name (e.g. `vpc`).

## Impact

Any consumer correlating this execution record against the logical component name used elsewhere (locks, instance-status uploads, affected-component uploads — all fixed to use the full logical name by #3102) will not find a match for path-style invocations. Lower frequency than the #3102 repro (path-style args are less common than named-component args), but the same class of cross-channel identity mismatch.

## Root cause

`cmd/terraform/plan.go` (and the equivalent in `apply.go`/`deploy.go`) captures the component identity for the exec-metadata parser closure eagerly from the raw CLI argument:

```go
var execComponent string
if len(args) > 0 {
execComponent = args[0]
}
shellOpts, stdoutBuf, stderrBuf := terraformCaptureShellOpts(execComponent, v.GetString("stack"))
```

This happens in `RunE`, **before** `cmd/terraform/utils.go`'s `resolveComponentPath` rewrites a path-style argument to its resolved logical component name (`info.ComponentFromArg = resolvedComponent`, ~line 1411). By the time the resolution happens, `execComponent` has already been captured and baked into the `terraformCaptureShellOpts`/`terraformExecMetadataParserFunc` closure.

## Proposed fix

Defer capturing `execComponent` until after path resolution completes, e.g. by threading it through `info.ComponentFromArg` at the point `terraformCaptureShellOpts` is actually invoked, rather than capturing `args[0]` upfront. Needs care across all three call sites (`plan.go`, `apply.go`, `deploy.go`) since they duplicate this pattern.

## Repro

```
atmos terraform plan ./components/terraform/vpc -s --ci
```
Inspect the resulting exec-metadata payload — `component` will be the literal path string, not the resolved logical name `vpc`.

## Context

Identified during code review of #3102 and explicitly scoped out of that fix (see `specs/003-fix-upload-component-name/spec.md` FR-008 and `contracts/upload-component-identity.md` in that PR) to keep the #3102 fix minimal and surgical. Tracked here per the repository's follow-up-tracking policy.

Contributor guide

Open the contributing guide

Research direction

Start in cmd/terraform/plan.go, apply.go, and deploy.go, then trace resolveComponentPath in cmd/terraform/utils.go and the exec-metadata capture helpers. Reproduce the path-style command from the issue and inspect its payload. Done means all three commands report the resolved logical component name rather than the raw filesystem path.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli, devops
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.