I'm not sure what's going on but forming a contract takes at least one minute and sometimes takes more than one hour:

An elapsed time in the above image shows how long one Client.Form took.

We've been getting this error since two days ago, and no contract formation succeeds.

That's strange because the last muse update was one week ago, though.

I think the problem is that shardAddr is expected to be in host:port as this flag definition:

shardAddr := flag.String("s", "localhost:9580", "host:port of the shard server")

but it tries to parse the address as a URL:

The server has all contracts with a slice and searches a contract sequentially. It might cause a performance issue if the client forms tens of thousands of contracts. Is there any plan to use some scalable database instead?

I think we need this PR lukechampine/us#119 to fix lukechampine/us#112.

Perhaps, it won't affect anything but those two lines should be in reverse order:

I think this should use http instead of https

because shard uses ListenAndServe instead of ListenAndServeTLS: https://github.com/lukechampine/shard/blob/55ee50ba70b592ae3fa5d82a73bfa413f6c30b0f/cmd/shard/main.go#L51.

I've just found siad v1.5.7 breaks tests, and I got this panic error.

=== RUN   TestServer
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x14e47d0]

goroutine 32 [running]:
lukechampine.com/muse.(*Host).handleConn(0xc0000a0dc0, {0x1638398, 0xc0000b6100})
        /Users/junpei/src/github.com/lukechampine/muse/muse_test.go:275 +0x630
created by lukechampine.com/muse.(*Host).listen
        /Users/junpei/src/github.com/lukechampine/muse/muse_test.go:229 +0x30

Does it change the protocol?

Currently, the internal Walrus address is randomly chosen, but unfortunately, it doesn't work with Kubernetes. It'd be nice if it supports an option flag to specify the address. Perhaps, -wl is good.

I'm trying to use muse from us as mentioned at lukechampine/walrus#13 (comment) but it looks like it doesn't expose any endpoints that walrus provides.

Could you expose endpoints walrus provides as same as endpoints shard provides so that walrus.Client can access it?

We get many of this warning here

Ideally, it'd be fine because at least the host could broadcast the contract transaction before responding to the form request. However, we also get no contract record error from hosts, which means the host doesn't have the contract.
If a transaction set is too large for our transaction pool, it seems too large for the host's transaction pool because a host would receive more transactions than a renter has.

Would it be possible that both renter and host don't broadcast the contract transaction but finish the protocol without any error? Then, the host doesn't store the contract but the renter keeps it as an active contract.

After the hard fork, it looks like no contract formation has succeeded.