fix: update PlanModifyList#347
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7045b299a2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if configVersions[i].Name.IsNull() { | ||
| planVersions[i].Name = types.StringValue(prevList[0].Name) |
There was a problem hiding this comment.
Avoid reusing prior ID while leaving name unknown
When configVersions[i].Name is non-null but unknown (for example, a recreated upstream random_uuid), this branch reuses a prior version ID but intentionally leaves planVersions[i].Name unknown. In Update(), known IDs go through the metadata-update path, where !curVersion.Name.Equal(newState.Versions[idx].Name) is true and ValueString() on the unknown name becomes an empty string, causing an invalid rename request (or a wrong blank name update). This regression is introduced by changing the backfill condition here and can break applies for unknown-but-configured names.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
When tf_vars change, the third loop resets the ID to unknown, so during Apply it goes through the "create new version" path where the name gets populated from the server response, so an empty name is expected. The unknown name never hits ValueString() in a rename request, or at least it shouldn't.
tf_vars breaks due to sensitive attribute being stripped on plan/update. Also breaks when the name of a version is unknown, breaking cases where the name of a version is inherited by another resource, like "random_uuid".