Paul Schoenfelder

@arjan Perhaps this occurs when performs the handoff from a third-party node? In other words, due to [this change](https://github.com/bitwalker/swarm/commit/770d3d6c4fc8cbc2d9ea736396b2944577d26d16)? In this case, the handoff request comes not from the tracker...

I guess the implication then is that it must be due to the latter of the two possibilities I described - at a high enough rate of churn, events may...

Unfortunately there generally isn't a way to know when a node is "fully" started, even how we detect when Swarm is started is a less than ideal. Providing prerequisites to...

I think the log level is appropriate, but we probably should evaluate a better way of either configuring or determining when a node is considered "available". This will come up...

The problem seems to be that the second node is still loading code when Swarm on the first node tells Swarm on the second node to start a process (resulting...

I'm open to improving the existing strategy, but time is always hard to find. If you have an existing implementation that you are using that you think is a strict...

Yeah there is definitely a bug in the topology change handler, I'll take a look. FYI, if you run `:sys.trace(Swarm.Tracker)` it will dump a lot more debug info if you...

@szlend Quick question, were you able to reliably reproduce this every time, or did it appear to occur randomly? If you didn't try multiple times that's cool, figure I would...

Ok cool, I'll be looking at it this afternoon, so hopefully I'll have an update soon.

Just an update, I was able to reproduce the problem, and I'm working on a fix (there are actually a couple of fixes, but I found them due to how...