OpenTofu中import块在destroy操作时可能引发资源重复销毁问题分析

问题背景

在OpenTofu 1.8.0-beta版本中，当使用import块导入资源后执行destroy操作时，系统可能会尝试销毁已经被销毁的资源实例。这一行为与预期不符，特别是在执行了针对性销毁（targeted destroy）后再次执行完整销毁时。

问题重现

考虑以下OpenTofu配置示例：

resource "random_integer" "a" {
  max = 10
  min = 1
}

import {
  to = random_integer.a
  id = "3,1,10"
}

resource "random_integer" "b" {
  max = 10
  min = 1
}

import {
  to = random_integer.b
  id = "5,1,10"
}

当用户执行以下操作序列时：

1. 初始化并应用配置
2. 执行针对性销毁（tofu destroy -target=random_integer.a）
3. 执行完整销毁（tofu destroy）

系统会在第三步尝试销毁已经被销毁的random_integer.a资源，而实际上应该只销毁random_integer.b。

技术原理分析

OpenTofu的destroy操作实际上是terraform apply -destroy的快捷方式，它会进入特殊的"destroy"规划模式。该模式内部会执行两个规划阶段：

1. 首先执行"normal"模式的规划，目的是确保先前状态尽可能准确地反映远程系统状态
2. 然后执行真正的destroy模式规划

问题出在第一个"normal"模式规划阶段。在这个阶段，系统会处理import块并尝试导入资源，即使这些资源可能已经被销毁。具体表现为：

• 在规划图构建阶段，PlanGraphBuilder会创建nodeExpandPlannableResource节点
• 这些节点会解析并处理import块
• 即使是在预销毁刷新阶段，系统仍然会处理import块

解决方案设计

最合理的解决方案是在预销毁刷新阶段跳过import块的处理。具体实现思路包括：

1. 在PlanGraphBuilder中设置preDestroyRefresh标志
2. 将该标志传递给具体的nodeExpandPlannableResource节点
3. 当该标志为真时，跳过import块的解析和处理逻辑

这种方案的优势在于：

• 改动范围小，风险低
• 不影响正常的import功能
• 符合destroy操作的语义（只关注状态中已存在的资源实例）

技术实现细节

在代码层面，主要修改点包括：

1. 修改PlanGraphBuilder的Build方法，将preDestroyRefresh标志传递给节点
2. 在nodeExpandPlannableResource中增加跳过import块处理的逻辑
3. 确保在destroy模式下不处理任何import块

总结

OpenTofu中的import块功能虽然强大，但在特定场景下（如destroy操作）需要特殊处理。通过分析内部规划流程和状态管理机制，我们确定了问题的根源并提出了合理的解决方案。这一改进将确保destroy操作更加符合用户预期，避免不必要的资源操作。