Found. It.

This was annoying. Took me way too long. And i got rid of it for a long time, but then resurfaced. Turns out the problem was a bad combination of Dial + Listen. (a peer would dial out and receive a connection from the same peer at the same time, ending with two Peer objectS). I got rid of it in the codebase, but surfaced in the tests, then fixed it.

// Dial connects to a particular peer, over a given network
// Example: d.Dial(ctx, "udp", peer)
func (d *Dialer) Dial(ctx context.Context, network string, remote peer.Peer) (Conn, error) {
    laddr := d.LocalPeer.NetAddress(network)
    if laddr == nil {
        return nil, fmt.Errorf("No local address for network %s", network)
    }

    raddr := remote.NetAddress(network)
    if raddr == nil {
        return nil, fmt.Errorf("No remote address for network %s", network)
    }

    // TODO: try to get reusing addr/ports to work.
    // madialer := manet.Dialer{LocalAddr: laddr}
    madialer := manet.Dialer{}

    log.Info("%s dialing %s %s", d.LocalPeer, remote, raddr)
    maconn, err := madialer.Dial(raddr)
    if err != nil {
        return nil, err
    }

// THIS. remote here is the value the function was called with. but after waiting
// on madialer.Dial, a new peer might have been added to Peerstore by Listen 
    if err := d.Peerstore.Put(remote); err != nil {
        log.Error("Error putting peer into peerstore: %s", remote)
    }

    c, err := newSingleConn(ctx, d.LocalPeer, remote, maconn)
    if err != nil {
        return nil, err
    }

    return newSecureConn(ctx, c, d.Peerstore)
}

Uh oh!

panic in net/swarm/conn.go:154 was triggered #174

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions