Fix 3 bugs in 1.21.1

[WhereisFff]

• fixed [Bug] 方块涂抹铜门复制为两个 #70
• fixed [Bug] 鱼缸加工bug #71
• fixed [Bug] 可推方块实体问题 #72

[Gugle2308]

以下是 PR #79 的代码审查结果：

---

代码审查摘要 — PR #79: Fix 3 bugs in 1.21.1

结论：评论（3 个修复均正确，无阻塞性问题，有少量代码质量建议）

---

🔍 修复分析

Bug 1：活塞推动可移动实体方块时 BlockEntity 引用泄漏

文件： PistonBaseBlockMixin.java
做法： 在 setBlock 方法开头添加 sharedBlockEntity.set(null)

✅ 正确。 旧的 @Share 注释变量在跨多次 push 迭代时可能持有前一次循环中残留的 BlockEntity 引用，导致后续逻辑拿到 stale 数据。显式清理是标准的防御性编程做法。

Bug 2：双格方块（门/大花）替换时另一半未被正确处理

文件： BlockCache.java
做法： 在 setBlock 中检测旧状态是否为 DOUBLE_BLOCK_HALF，自动处理另一半 + 推迟邻接更新到批量提交完成后

✅ 核心逻辑正确：

• 旧状态是双格的一半 → 定位另一半 → 匹配验证 → 设置两半
• 新状态也是双格 → 正确分配 LOWER/UPPER
• 新状态不是双格 → 目标位置设新状态、另一半清空为空气
• deferredNeighborUpdates 机制（UPDATE_CLIENTS + 事后 updateNeighborsAt）防止了批次内级联邻接更新

⚠️ 潜在行为变化： 如果一个位置原本是门的 UPPER 半，现在设一个普通方块，LOWER 半会被自动清空（设为空气）。这通常是期望行为（因为不能只有一半），但在某些极端场景（如手动半边替换管线）可能引入意外。建议确认使用该 BlockCache 的调用方都预期此行为。

💡 建议： setSingleBlock() 方法第一行调用了 this.getBlockState(pos) 但未使用返回值——这是旧代码中遗留的无用调用，可考虑一并清理。

✅ 附带修复： 旧 BlockCache.java 文件末尾缺少 POSIX 换行符（\ No newline at end of file），本次修正常规化。

Bug 3a：Item 缓存中 grow() 允许不兼容物品混合

文件： AbstractCacheElement.java
做法： 新增类型守卫 + 修复 simulate 初始化的 type 选择

✅ 关键修复： 当 simulate 已有物品且传入的 stack 类型不匹配时，返回未修改的副本（不消费物品）。这防止了不同物品在缓存中被错误混合。

✅ 额外修复： this.simulate 初始化从 this.type.isEmpty() ? stack.copyWithCount(growCount) : this.type.copyWithCount(growCount) 改为 stack.copyWithCount(grownCount)。旧代码中当 this.type 不为空时使用了错误的目标类型！新代码始终使用实际传入的 stack 类型，语义正确。同时 grownCount 已经过 getCapacity 钳制，不会溢出。

Bug 3b：ICacheInputOutputImpl.grow() 记录了未消费物品的元素

文件： ICacheInputOutputImpl.java
做法： 仅将实际消费了物品的元素加入操作集

✅ 正确。 旧代码将所有元素加入操作集，即使某些元素没有消费物品（因物品类型不匹配等）。回滚时会无辜地对这些元素调用 shrink(0)（无副作用但浪费）。新代码更精确——只有 remaining.getCount() < previousCount 的元素才加入回滚集。

Bug 3c：ItemHandlerCacheElement.sync() 不安全的栈突变

文件： ItemHandlerCacheElement.java
做法： 将 setCount 模式改为 extractAll + insert(simulate) 模式

✅ 正确。 旧代码直接对 getStackInSlot() 返回的 stack 调用 setCount()，这依赖于 handler 实现是否支持对返回的 Stack 引用进行变异——许多 handler 实现不会将这种变异持久化。新代码先 extractItem（支持容量/策略检查）再 insertItem，符合 IItemHandler 的正常使用方法。

💡 注意： 新代码在 slot 原有物品不为空但 simulate 也为空时，会执行 extract（清空 slot）但不 insert——结果为空的 slot。这与旧代码行为不同（旧代码只设 count，可能设成 0）。但这是更正确的行为：如果 simulate 为空，slot 就应该为空。

---

✨ 整洁性

• 5 个文件、70 新增 / 14 删除，粒度合适，每个修复独立可追溯
• 无新增 TODO/FIXME
• 无硬编码凭据或密钥泄露
• 无一端引入新依赖或新配置项
• 所有三元/条件逻辑变更已验证极性正确

---

💡 建议（非阻塞）

1. BlockCache.java L125 占位调用： this.getBlockState(pos);（第 125 行）的返回值未被使用，这是旧代码遗留的无副作用调用，建议一并移除。

2. javax.annotation.Nullable 注解： BlockCache.java 仍使用 javax.annotation.Nullable（非这个 PR 引入，是旧代码）。如果项目后续计划统一为 org.jspecify.annotations.Nullable，可以在这里顺手迁移。

---

🟢 看起来不错

• 三个 bug 的修复方向和实现均正确，每个修复都有清晰的意图
• deferredNeighborUpdates 机制设计得当——批次完成后统一触发邻接更新，避免级联
• Item 缓存的三处修复（类型守卫、初始化修复、精确记录、extract/insert 模式）相互配合，完整性好
• 所有新 import 合理且已排序
• 测试覆盖率预期：活塞推送双格方块场景应增加测试覆盖

---

由 Hermes Agent 审查

[Gugle2308]

代码审查摘要：PR #79 — Fix 3 bugs in 1.21.1

结论：批准（Approve）

三个 Bug 修复逻辑正确、改动干净，无引入新问题。

---

📋 文件变更总览

文件	改动量	关联 Issue
PistonBaseBlockMixin.java	+1	#70
BlockCache.java	+67 / -1	#71
AbstractCacheElement.java	+2 / -2	#72
ICacheInputOutputImpl.java	+5 / -2	#72
ItemHandlerCacheElement.java	+3 / -3	#72

共 5 个文件，约 80 行有效变更。

---

🟢 严重问题

无。

---

🟡 警告

无。

---

💡 建议

1. BlockCache.setBlock() — getBlockState(pos) 在 setSingleBlock 中的无效果调用

   第 84 行 this.getBlockState(pos); 返回值未使用，仅利用其副作用（将旧状态缓存进 cache map）。原始代码中已有此调用，非本次 PR 引入。建议后续可提取为更明确的方法或不调用。

2. BlockCache.setBlock() — 可能的双重设置竞态

   如果两次独立调用 setBlock() 分别作用于同一个双方块的两个半（假设外部逻辑先设置 LOWER，再手动设置 UPPER），第一次调用已通过 setSingleBlock 同时设置了 pos 和 otherPos，第二次调用 getBlockState(otherPos) 会读到已模拟好的状态（非原 DOUBLE_BLOCK_HALF），走 fallthrough 路径再次 setSingleBlock。但这不影响正确性——后一次写入会覆盖前一次，结果一致。只是多一次无意义操作。实际配方模拟场景中应不会出现此模式，可忽略。

---

✅ 修复分析

#70 — PistonBaseBlockMixin: 共享变量泄漏

+sharedBlockEntity.set(null);

问题：Mixin 中 @Share 注解的 sharedBlockEntity 在迭代推进方块列表时，如果前一轮的方块是 IMoveableEntityBlock（设置了 sharedBlockEntity），而当前方块不是，则 sharedBlockEntity 会携带旧值进入本轮，导致非可移动方块错误地携带了上个方块的 BlockEntity。

修复：在每轮迭代开始前显式置 null。正确 ✅

---

#71 — BlockCache: 双方块替换时邻居更新破坏对方

问题：当模拟替换双植物/门等双块方块（DOUBLE_BLOCK_HALF）时，依次设置两个半块会在设置第一个后立即触发邻居更新，破坏另一半（因为另一半检测不到「自己与匹配的另一半」而自动掉落/破裂）。

修复：

• setBlock() 新增检测：若旧状态是双块方块，找到另一半，同时设置两半（通过 setSingleBlock 用 Block.UPDATE_CLIENTS 标记延迟邻居更新）
• accept() 新增两阶段提交：先用 UPDATE_CLIENTS 标记设置所有块（不触发邻居更新），全部设置完成后统一对延迟位置调用 updateNeighborsAt()

验证要点：

// 双块匹配条件：另一半必须是同种方块且 HALF属性互补
boolean isMatchingOtherHalf = oldOtherState.is(oldState.getBlock())
    && oldOtherState.hasProperty(BlockStateProperties.DOUBLE_BLOCK_HALF)
    && oldOtherState.getValue(BlockStateProperties.DOUBLE_BLOCK_HALF) == otherHalf;

检查无误 ✅

Batch 邻居更新：updateNeighborsAt() 在 simulatedEntity 和 loadWithComponents 处理之后、deferredNeighborUpdates.clear() 之前执行，顺序正确 ✅

---

#72 — Cache Simulation: 物品类型不匹配与计数错误

三个子修复：

① AbstractCacheElement.grow() — 跨类型保护

+if (!this.simulate.isEmpty() && !ItemStack.isSameItemSameComponents(stack, this.simulate)) return copy;

防止 simulate 中已有物品 A 时尝试 grow 物品 B 导致类型混淆。✅

② AbstractCacheElement.grow() — 容量超限计数修复

-this.simulate = this.type.isEmpty() ? stack.copyWithCount(growCount) : this.type.copyWithCount(growCount);
+this.simulate = stack.copyWithCount(grownCount);

旧代码使用了 growCount（输入的原始数量），而非 grownCount（容量限制后的实际可放入数量）。当输入 stack 超过容量时，simulate 被设置为超出值，导致容量越界。新代码使用 grownCount = min(capacity, simulateCount + growCount) 修正。✅

同时移除了对 this.type 的三元判断——类型匹配现在由 line 127 的 guard 保证，简化逻辑且更精确。

③ ICacheInputOutputImpl.grow() — 仅记录实际消耗物品的元素

-int previousCount = stack.getCount();
-ItemStack remaining = element.grow(stack, false);
-if (remaining.getCount() < previousCount) {
-    elements.add(element);
-}
-stack = remaining;

旧代码将所有元素加入 elements 集，即使元素未实际消耗物品（类型不匹配或已满）。回滚时会对未参与的元素错误执行 shrink。新代码通过比较 grow 前后的 count 变化决定是否记录，正确 ✅

④ ItemHandlerCacheElement.sync() — 类型安全同步

-if (stack.isEmpty()) {
-    this.iItemHandler.insertItem(this.slot, this.simulate, false);
-} else {
-    stack.setCount(this.simulate.getCount());
-}
+if (!stack.isEmpty()) {
+    this.iItemHandler.extractItem(this.slot, Integer.MAX_VALUE, false);
+}
+if (!this.simulate.isEmpty()) {
+    this.iItemHandler.insertItem(this.slot, this.simulate.copy(), false);
+}

旧代码当 slot 已有物品且 simulate 类型不同时，stack.setCount() 会错误修改 slot 中现有物品的数量（类型不变，计数值变），导致物品重复/丢失。新代码改为：先全量提取，再全量插入——无论类型是否变化，均正确处理。✅

---

📝 附加检查

检查项	结果
无改用例泄露（TODO/FIXME/HACK）	✅ 无
无硬编码密钥/凭据	✅
EOF 末尾换行符已修复	✅（原 BlockCache.java 末尾缺失，PR 已补上）
无新文件遗漏 register() 调用	✅ 不涉及注册
不影响构建系统	✅ 无 build.gradle 变更

---

总结：三个 Bug 修复的根因分析准确，修复方案正确无副作用，代码质量良好。建议批准合并。

[Gugle2308]

🌿 Roseau API Breaking Change Report

Module	Status	Breaking Changes
codec	⚪ Skipped	—
collision	⚪ Skipped	—
config	⚪ Skipped	—
integration	⚪ Skipped	—
moveable-entity-block	⚪ Skipped	—
network	⚪ Skipped	—
rendering	⚪ Skipped	—
space-select	⚪ Skipped	—
font	⚪ Skipped	—
util	⚪ Skipped	—
explosion	⚪ Skipped	—
rpc	⚪ Skipped	—
multiblock	⚪ Skipped	—
recipe	⚪ Skipped	—
registrum	⚪ Skipped	—
sync	⚪ Skipped	—
wheel	⚪ Skipped	—
main	⚪ Skipped	—

Full CSVs: see the Artifacts section of this workflow run.

[Gugle2308]

PR #79 — 状态：closed

根据审查工作流 Step 0 的要求：PR 状态为 closed → 停止，不发评论。

该 PR 已被合并或关闭，无需执行代码审查。