Skip to content

Conversation

@SarahFrench
Copy link
Member

@SarahFrench SarahFrench commented Nov 21, 2025

(Potential) Fix following changes in #33116

Prior to this change, if a user runs a state show command with an address for a resource that existed in state but didn't match the current schema of the resource then the user would see

  • exit with code 0
  • Error logged to stderr, for example : "Failed to marshal state to json: unsupported attribute "foobar""
  • This message logged to stdout: "The state file is empty. No resources are represented"

This is misleading because the state file used for state show isn't empty, its just that the command hasn't been able to assemble a jsonformat.State correctly for output. And that suggests that we should return with code 1 before that is attempted.

Target Release

1.15.x

Rollback Plan

  • If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

  • This change is user-facing and I added a changelog entry.
  • This change is not user-facing.

…annot be marshalled for rendering

Prior to this change, when running a `state show` command with an address for a resource that existed in state but didn't match the current schema of the resource, users would see the "Failed to marshal" error but would also see output saying "The state file is empty. No resources are represented". This is misleading, as the state file isn't empty. Also, the command would exit with code 0 despite the error.
@SarahFrench SarahFrench force-pushed the sarah/state-show-exit-code-1 branch from 9accd41 to 1f6b657 Compare November 21, 2025 18:33
@@ -0,0 +1,5 @@
kind: BUG FIXES
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be considered a breaking change?

I'd argue not, as the old behaviour was misleading and incorrect, though someone could have built a system that relied on the command not failing somewhere.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On some level every fix in terraform has the potential to be a breaking change - the longer the behavior is present, the more likely people have already accounted for it in their workflows.

This is about the least-concerning breaking change I can think of since it's not a change in anything that modifies state and even if someone's automation for e.g. carefully checks for that error message if the show command succeeds (to understand that it actually failed), changing the exit code to properly return 1 probably isn't going to break anything.

I'd still call it a bug fix, but not a bad idea to get some other opinions! My process instincts are outdated

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah agreed, previous projects I've worked on have been strict about breaking changes but in those cases state was always being modified. I don't think we have a blanket block on breaking changes here in Core as there's more grey area, but figured I'd flag to the reviewer anyways.

I'm happy to go ahead with this as a bug fix.

@SarahFrench SarahFrench marked this pull request as ready for review November 21, 2025 18:34
@SarahFrench SarahFrench requested a review from a team as a code owner November 21, 2025 18:34
@SarahFrench SarahFrench merged commit 4381860 into main Nov 24, 2025
15 checks passed
@SarahFrench SarahFrench deleted the sarah/state-show-exit-code-1 branch November 24, 2025 15:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants