Tunnelled connections stop after relog until replaced with Mekanism reactor (ATM10 TTS, SFM 4.34)

[TeamDman]

Report

Discord report from TheVoos (23 September 2026): tunneled SFM connections associated with a Mekanism fission reactor reportedly stop working after each relog and resume only after the tunnelled blocks are broken and replaced.

Reported environment:

• Modpack: ATM10 To the Sky 2.0.4 (Minecraft 1.21.1 / NeoForge).
• SFM: 4.34 (the 1.21.1 release is 4.34.0).
• Mekanism version, exact tunnel block(s), resource type, and singleplayer vs dedicated-server status: not yet known.

Reporter tested hoppers in a separate SFM-only superflat world and did not reproduce the failure there. That is a useful control but does not isolate the Mekanism capability, modpack interaction, or original world/reload path. The next player-side comparison should use a new superflat world in the same ATM10 TTS instance before removing mods.

Expected / observed

Expected: after leaving and rejoining the world/server, the same cable/tunnel setup keeps transferring without replacement.

Observed (reported, not yet independently reproduced): transfer stops after relog; breaking and replacing the tunnelled block(s) restores it.

Investigation priority and reproduction matrix

High priority because the workaround requires rebuilding a working automation setup after every relog.

1. Run the existing tunnelled-block regression tests on 1.19.2, then add a targeted chunk-unload/reload and capability re-acquisition probe if the current tests do not exercise that boundary.
2. Test the reported 1.21.1 / NeoForge / SFM 4.34.0 combination with Mekanism. Compare same-pack superflat, SFM-only + Mekanism, and the existing world if a safely shareable reproduction is available.
3. Distinguish client relog, world exit/reopen, server restart, and chunk unload/reload; these may take different lifecycle paths.
4. If a GameTest cannot cross the relevant boundary, use a puppet to run the world exit/re-entry flow. Keep the test fixture disposable; do not manipulate an active reactor.
5. Check whether an SFM rebuild/cache refresh alone restores transfer. A historical, possibly related report, [BUG] Manager stops working #140, involved cached handlers after relog; this is a hypothesis, not an established cause here.
6. Preserve a failing regression and a nearby passing control before making a fix.

Information needed to reduce the case

• Exact SFM and Mekanism jar versions; singleplayer/LAN/dedicated server; whether server restart is involved.
• Which tunnelled SFM blocks, which faces, the resource type (item/fluid/chemical/energy), and whether the reactor multiblock is formed before/after relog.
• The program and labels (with sensitive coordinates/server names redacted if desired), plus a small layout screenshot.
• Whether ordinary Mekanism machines or hoppers fail in the same pack, and whether SFM's rebuild control restores operation without block replacement.
• Client/server log excerpt around the first failed transfer, if available; redact tokens, addresses, and personal data.

This issue tracks the new report separately from #140 because the reporter's Mekanism reactor and tunnelled-block trigger have not yet been proven to share that cause.

[TeamDman]

Investigation update (23 September 2026): on 1.19.2, a new focused GameTest with Mekanism energy cubes passed 1/1. Both a direct path and a tunnelled path transferred before and after the destination block entity was absent for 20 server ticks and then restored. The existing tunnelled_cable_capability_west baseline also passed 1/1. This does not reproduce a full relog, reactor multiblock, or the reported 1.21.1/NeoForge environment. Next is a disposable checkout of the published 4.34.0-1.21.1 tag with its pinned Mekanism test dependency, then an actual world/session transition if needed. No root cause or fix is claimed yet.

[TeamDman]

Reproduction update (23 September 2026): on an isolated checkout of the published SFM 4.34.0 / Minecraft 1.21.1 / NeoForge source tag, with the tag's hash-pinned Mekanism 10.7.4.60 test dependency, a new three-case GameTest gives:

• direct_mekanism_cached_energy_recovery: pass.
• tunnelled_mekanism_fresh_energy_recovery: pass.
• tunnelled_mekanism_cached_energy_recovery: fail after the far Mekanism energy cube has been absent for 20 ticks. The cached consumer still sees its old capability: “retained a capability while its Mekanism endpoint was absent.”

This isolates a real tunnel proxy / capability-cache invalidation defect in the published 1.21.1 source. The test uses a Mekanism energy cube, not a fission reactor, and removes/restores a block entity rather than exiting/rejoining the world. It is therefore a likely mechanism for the report, not yet proof that it is the exact reactor/relog failure. The red test is kept in a disposable exact-tag worktree; no production fix has been applied. NeoForge's 1.21.1 capability guidance requires invalidating caches when a provided capability appears, disappears or changes. Next: verify the relog path and design a production fix with this red test retained.

[TeamDman]

Further characterization on the same published 1.21.1 / SFM 4.34.0 tag: a fourth cached-consumer test passed 1/1 when it removed and re-placed the SFM tunnel after the Mekanism endpoint returned, while keeping the consumer's BlockCapabilityCache object. The restored handler was distinct from the detached one and accepted energy into the live cube. This reproduces the workaround pattern reported by TheVoos (tunnel replacement restores access) in a controlled energy-cube fixture. It still does not prove the fission reactor's exact relog path; that is being tested separately.

[TeamDman]

Actual relog control (1.19.2): a new isolated client puppet created its own flat save, passed the direct/tunnelled Mekanism energy-cube baseline, shut down the integrated server, reopened the same save through Minecraft's title/world-opening flow (including the expected Forge experimental-world confirmation), and verified a new integrated server instance. The post-rejoin probe logged direct_received=true tunnel_received=true; the puppet finished with failed=0 total=1 and CLI exit 0. This is a scoped non-reproduction on 1.19.2 energy cubes, not a claim about the reporter's 1.21.1 ATM10 TTS fission reactor. The exact 4.34.0/1.21.1 cached-tunnel red case and replacement recovery remain the primary reproduced defect. A follow-up puppet rerun is only improving the after-rejoin screenshot timing; it does not change the passing server assertion.

[TeamDman]

Evidence clarification (23 September 2026): the cached-tunnel red test stops at the absent-provider assertion, before checking whether a no-replacement tunnel transfers after the Mekanism cube returns. A separate replacement case passes. Thus we have proved a stale cached capability while the far provider is absent and observed recovery after replacement, but have not proved replacement is necessary after restoration or that this is TheVoos' reactor/relog failure.

The 1.19.2 real-rejoin puppet has now passed a visual-timing rerun as well: both preview screenshots show the disposable world fixture, and the post-rejoin assertion again reports direct_received=true and tunnel_received=true on a new integrated server. This remains a scoped non-reproduction for 1.19.2 energy cubes. The exact published 4.34.0/1.21.1 client-rejoin probe is in progress.

[TeamDman]

Exact-release real-rejoin control (23 September 2026): on an isolated checkout of the published SFM 4.34.0 / Minecraft 1.21.1 tag, a test-only client harness created a disposable flat world with pinned Mekanism energy cubes, exited it, and reopened the same save on a distinct integrated server. The final run passed its headless fixture (1/1), logged new_server=true and direct_received=true tunnel_received=true after rejoin, and exited 0 without manual warning confirmation. The relog probe passed twice. This does not reproduce the reported ATM10 TTS fission-reactor symptom; it narrows it to a reactor-specific, pack-specific, player-layout, resource/face, or different session transition, among other possibilities. The separate cached-tunnel/absent-provider GameTest remains red. Current 1.21.1 source has the same tunnel proxy and SFM cache files as the published tag, but that source comparison is not a runtime fix verdict. Next I am checking transfer after provider restoration without replacing the tunnel, then need the reporter's same-pack minimal layout and exact relog meaning.

[TeamDman]

Focused follow-up on the published 4.34.0 / 1.21.1 tag: I added a fifth GameTest that keeps the same cached tunnel consumer, removes the far Mekanism energy cube, restores a new cube, and deliberately continues past the earlier absent-provider check without replacing the tunnel. At tick 80 it fails: the retained capability accepted 1,000 energy but the live restored cube still held 0; the energy went to a detached provider. The expected-red test exited 1. The separate tunnel break/re-place case passes with that same consumer-cache pattern. This now demonstrates both post-restoration failure without replacement and recovery with replacement in the energy-cube fixture. It still does not establish that a world relog of a formed fission reactor causes the same provider transition: the exact-release energy-cube client rejoin passed. We need the reporter's same-pack reactor layout, connected resource/face, exact Mekanism Generators jar, and whether client reconnect, world reopen, or server restart is the trigger before assigning this as the root cause of the report. No production fix has been applied.

[TeamDman]

Second report, separate trigger (23 September 2026): druidbruce reports the same break-and-re-place requirement in Techopolis 3 on Minecraft 1.21.1, but not after relog. Their description: when either side changes state for certain blocks, such as placing the tunnel first and then placing/updating a neighboring block described as "mekanism installers", the tunnel must be broken and re-placed before both sides recognize it. We have not confirmed the exact block name, SFM version, loader, connected resource/face, or whether placing the neighboring block without first querying the tunnel is enough to trigger it.

This is a distinct observation, not proof that the ATM10 TTS reactor relog has the same cause. It strengthens the provider-change/capability-invalidation hypothesis already supported by the exact-4.34.0 cached energy-cube red test. A focused tunnel-first/neighbor-second GameTest with a direct or fresh-query control is now being prepared. The most useful follow-up from druidbruce is the exact block ID, SFM and pack versions, minimal placement order, and whether tunnel replacement alone restores it.

[TeamDman]

Placement-order GameTest result (published SFM 4.34.0 / Minecraft 1.21.1 source tag, pinned Mekanism energy cube): both variants query a BlockCapabilityCache before the neighboring provider exists, then place the cube. The direct cached connection passes. The tunnelled cached connection stays absent after placement, although a fresh tunnel lookup succeeds and transfers energy into the live cube. The focused pair had an expected-red exit of 1. This gives a controlled tunnel-first/neighbor-second failure consistent with druidbruce's reported transition and the existing tunnel invalidation hypothesis. It does not reproduce their unidentified "mekanism installers" block or Techopolis 3 pack, nor does it prove that TheVoos' reactor relog has this trigger. Test-only fixture: platform/minecraft/src/gametest/java/ca/teamdman/sfm/gametest/tests/compat/mekanism/MekanismLateEnergyProviderGameTestGenerator.java in a disposable exact-tag worktree. No production code or dependencies changed.

[TeamDman]

Reporter clarification: "mekanism installers" refers to Mekanism installer items that upgrade an existing machine into the next factory tier. It is not the name of a neighboring block. The prior tunnel-first/energy-cube-placement GameTest remains a useful provider-appearance control, but it does not reproduce using an installer on an existing machine. I am tracing the installer upgrade and capability invalidation path at the exact Mekanism 1.21.1-10.7.4.60 tag pinned by SFM, then comparing a newer 1.21.1 tag if relevant. Techopolis 3 has public 1.21.1 releases, but the reporter's pack and Mekanism versions are still unknown; do not assume the SFM test pin matches their instance.

[TeamDman]

Installer-path update (separate from the fission-reactor relog report): SFM 4.34.0 for Minecraft 1.21.1 pins Mekanism 10.7.4.60; its source tag v1.21.1-10.7.4.60 is commit 710d867. In Mekanism ItemTierInstaller.useOn, the installer replaces the machine block at the same position, transfers upgrade data, then invalidates that machine capability. A focused GameTest on the published SFM tag used an actual Advanced Tier Installer on a Basic Enriching Factory. The direct cached-capability control passed, and a fresh lookup through the tunnel reached the upgraded factory. The original cached tunnel capability still accepted 1,000 FE but the live upgraded factory received zero. This is a reproducible tunnel capability invalidation failure for the installer upgrade path (expected-red run: 1 of 2 required tests failed), not proof of the separate fission-reactor relog trigger or of the reporter exact Techopolis 3/Mekanism versions. The test is currently test-only in a disposable worktree; no production fix or dependency change has been made. Further report details needed: Techopolis 3 pack release, SFM and Mekanism versions, installer tier, starting machine, connected resource/face and placement order.

[TeamDman]

New chunk-border lead from the Discord discussion: TheVoos reports both reactor ports and the tunnel in one chunk, but the full reactor footprint is not yet established. Druidbruce suspects a large reactor crossing chunks may reform as chunks load. In SFM-pinned Mekanism 10.7.4.60, multiblock formation reads every structure coordinate without force-loading missing chunks; formation fails while a required chunk is unavailable. One elected member ticks shared reactor data, while each shell member checks structure and invalidates its own capabilities when formed state changes. Thus it is not specifically two ticking blocks in different chunks; same-chunk ports+tunnel do not rule out a cross-chunk reactor reload. This is a source-backed hypothesis, not a reproduced reactor relog failure. Existing passing relog tests used energy cubes, not a reactor. Useful non-destructive observations: show the full reactor footprint with chunk borders, note whether the reactor is formed and all its chunks are loaded after relog, and compare direct port access with fresh and retained tunnel access. Do not break a live reactor to test this. The exact ATM10 TTS Mekanism jar and server/client relog lifecycle are still needed.

[TeamDman]

Video evidence update (23 September 2026): TheVoos supplied a private 3m36s recording; I reviewed its narration and sampled frames. On the post-login attempt, steam reaches the turbine, but reactor water falls and its enabled failsafe trips. Updating adjacent Mekanism/SFM blocks did not help. The player then broke and replaced two adjacent Tunneled Fancy Inventory Cable blocks at about 157–162 s and reported recovery. The reactor briefly ran afterward (water shown at 133.1 million mB before, 114.7 million mB around 174 s), but the video does not show a post-replacement reactor-status screen or measured sustained water return; later turbine readings are nearly static. No chunk-border overlay is visible.

This is not an all-or-nothing transfer observation: steam delivery and condensed-water return are separate capability paths. The turbine's ~29.67 million mB steam overlay is stored content, not a transfer rate; its energy buffer is far below the displayed 12.39 GFE capacity in sampled frames. In pinned Mekanism source, the turbine vent caches its neighboring fluid target and auto-ejects condensed water each tick, without requiring an SFM manager tick (vent cache, flow and output). A stale/missing target across the SFM tunnel remains plausible, but replacement changes both cable connections at once and the clip cannot establish which cache, if any, is stale. Insufficient turbine flow or condenser output could also cause net reactor-water loss while some steam moves.

Most useful safe next evidence: with the failsafe still enabled, capture reactor heating rate and coolant change alongside turbine actual flow and maximum water output just before the trip, and the same readouts after replacement if possible. Show the whole reactor with chunk borders to test the separate load-order lead. Please do not disable the failsafe or dismantle the live reactor for this investigation. The exact Mekanism/Generators jar and relog type are still needed. No production fix is claimed.