Hi,
At WCHL (WORLD COMPUTER HACKER LEAGUE 2025), we are having several devs facing the error of “unable to connect loop”.
This is the most recent example:
I have also opened an issue one month ago, it was already confirmed and it’s still pending triage: Pocket IC not handling well a devcontainer stopping · Issue #4264 · dfinity/sdk · GitHub
Opening this post here to give more visibility and urgency into fixing this in a future dfx version please.
Thanks for your attention,
Tiago
This could happen if the PocketIC instance is not stopped properly (and thus its state is corrupted). To stop the PocketIC instance properly, you should:
dfx stop;Ctrl-C in the terminal tab executing dfx start (or send SIGINT - corresponding to Ctrl-C - to dfx start in a non-interactive environment).And you should not run dfx start after dfx killall. In other words, if you have to run dfx killall (or kill the container etc.), then you should use dfx start --clean afterwards.
I took a note to produce a comprehensible error message in PocketIC if the state is corrupted.
Hi @mraszyk ,
I confirm the cause is from what you are saying, and --clean is a good quick fix.
But from your text, you are giving me the impression the only fix is to improve the error message. 
I would like to give more visibility to the fact that this is “very annoying”. We are forced almost every other day to do a dfx start --clean, only because we restarted the computer or the codespace shut down after being idle.
Many production devs have complex local deployment scripts of a few canisters, this usually takes several minutes. This is an unnecessary hindrance that wasn’t here on local replica.
I never had issues with corrupted state before Pocket IC came into default (after v0.25).
This is not critical or urgent, but many of us would appreciate it if this hindrance was avoided altogether 
Please let me know if it’s possible. Thanks
This is the actual fix I proposed (improving the error message is only meant to avoid confusion).
@mraszyk I believe what Tiago meant is that the issue happens because developers can’t run dfx stop or press Ctrl-C. It occurs when the computer or code space shuts down automatically while pocket-ic is running, without forwarding a SIGTERM to the terminal, leaving developers with no way to stop it manually.
This is because the replica (used instead of PocketIC before) relied on the backup and restore mechanism of the consensus layer of the ICP stack. PocketIC does not instantiate the full consensus layer (so that it can efficiently emulate multiple subnets each with many nodes locally) and thus PocketIC cannot rely on that backup and restore mechanism. Consequently, PocketIC must be shut down gracefully to have its state preserved properly. We could consider implementing backup and restore mechanism in PocketIC, but that would be a pretty major feature and thus it won’t be available any time soon.
One thing we could consider is to just accept that on a dirty shutdown you lose any changes since the last checkpoint. It might be confusing some tests, and they would still need to --clean if that happens, but in most cases it would simply revert to a last good state.
The error itself points to an issue of setting the correct timestamp contradicting the loaded state. This issue can likely be fixed in isolation without implementing a full replay. If we do that, we get to a situation as described above, where we might lose the last changes before the crash, but at least you don’t lose the whole state every time.
Good point, @stefan.schneider! I’ve implemented your suggestion in this PR.
Let me again point out that if we merge it, failing to stop a PocketIC instance would not result in a failure, but in silently losing some recent changes.