Private Transactions failure about quorum HOT 8 CLOSED

Hi I have exactly the same issue: deployed two nodes of 7nodes on two physical machines as a permissioned network of two. Public contract is deployed fine. Private contract using example fails with:

Error: Non-200 status code: &{Status:500 Internal Server Error StatusCode:500 Proto:HTTP/1.0 ProtoMajor:1 ProtoMinor:0 Header:map[Server:[Warp/3.2.13] Content-Type:[text/plain; charset=utf-8] Date:[Tue, 24 Apr 2018 00:25:52 GMT]] Body:0xc4215e9000 ContentLength:-1 TransferEncoding:[] Close:true Uncompressed:false Trailer:map[] Request:0xc42176ed00 TLS:}

I have started Contesllation on those two nodes in the same way as in 7nodes.
Could you please help with that?

from quorum.

i am getting the same error My logs are :---

Error encountered, bailing. Network state unknown. Review successful transactions manually.
Error: Non-200 status code: &{Status:500 Internal Server Error StatusCode:500 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Server:[Warp/3.2.13] Date:[Fri, 11 May 2018 19:48:33 GMT]] Body:0xc437979400 ContentLength:-1 TransferEncoding:[chunked] Close:false Uncompressed:false Trailer:map[] Request:0xc4224c9a00 TLS:}
at Object.InvalidResponse (C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:44006:16)
at C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:359607:36
at C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:86262:11
at C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:322668:9
at XMLHttpRequest.request.onreadystatechange (C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:324093:13)
at XMLHttpRequestEventTarget.dispatchEvent (C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:71245:18)
at XMLHttpRequest._setReadyState (C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:71535:12)
at XMLHttpRequest._onHttpResponseEnd (C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:71690:12)
at IncomingMessage. (C:\Users\kunal\AppData\Roaming\npm\node_modules\truffle\build\cli.bundled.js:71650:24)
at emitNone (events.js:111:20)

from quorum.

looks like this is the issue (found in constellation log file)

sreqTo = ["eh+2s0dX1vFwy9CKlrDiX+4uXfru6HDssmMFnKFikiI="]}); sendRequest: Errors while running sendPayload: [Left "Unknown recipient\nCallStack (from HasCallStack):\n error, called at ./Constellation/Node.hs:133:21 in constellation-0.1.0.0-6xjvDZGts4SA8gHwXEhJYJ:Constellation.Node"]

But the other recipient constellation node is running . How can I check that they can see each other ?

For your information, public transactions are working OK.

from quorum.

When Constellation nodes start, they reach out to the peers listed in otherNodeUrls to exchange information about keys and their recipients. After the initial synchronization they will repeatedly re-sync every 5 minutes. If the first sync fails, it is not retried until 5 minutes later.

In the 7nodes example, the first constellation node has no other peers, and is the "boot node." The other constellation nodes each list the first node in their otherNodeUrls, meaning they immediately synchronize with the first node upon startup. If the first node is not up when they start, it will take around 5 minutes before the nodes try again, and thus 5 minutes before they have information about all the keys (recipients) in the network, since they will not discover and synchronize with each other (they are not listed in otherNodeUrls.)

Thus, to be able to immediately address every recipient in the network, you should make sure that the Constellation nodes start in an order that allows an immediate synchronization, e.g. by starting the nodes that reference the bootnode after the bootnode. You can also list all the possible peers in otherNodeUrls.

In the future, we plan to:

• Make the synchronization more powerful, in particular making nodes synchronize with each other more aggressively at startup: Consensys/constellation#13
• Allow the user to access information about currently known peers and recipients, and to trigger a resynchronization, through the API: Consensys/constellation#14 / Consensys/constellation#15

from quorum.

Thank you so much for the clarification. Makes total sense to me now.

from quorum.

Hi @patrickmn
contractDeployment.txt
,
By following quorum-examples/7Nodes we can able to implement a 3 node cluster. Three nodes deployed in 3 different machines. I have node keys and pubs for all 3 nodes. But while doing private transaction from Boot node to voter node I can able to reproduce this error.

Error: Non-200 status code: &{Status:400 Bad Request StatusCode:400 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Date:[Tue, 17 Apr 2018 09:46:08 GMT] Server:[Warp/3.2.12]] Body:0xc42776efc0 ContentLength:-1 TransferEncoding:[chunked] Close:false Uncompressed:false Trailer:map[] Request:0xc424d851d0 TLS:}

Could you please provide any solution for this. Thanks in advance.

from quorum.

I also faced this problem.
But fortunately found out the solution.

I am running:
Geth
Version: 1.7.2-stable
Git Commit: 0905eda
Quorum Version: 2.0.0
Architecture: amd64
Network Id: 1
Go Version: go1.8.7
Operating System: linux
GOPATH=
GOROOT=/usr/lib/go-1.8

Quorum :2.0.0

I have been facing this problem when trying to deploy private contracts into any node of my defined 3 node cluster.
One thing to node in this is that Quorum does;t support self public key into the privateFor section.
Having considered that if you are still facing issue, you might want to check:

1. if you have added "/" at the end of url in node.conf
2. if you have correctly placed the enode, raft port and geth port into the static-nodes.json file
3. if you have mistakenly replaced https with http in node.conf file

Having checked for this mistakes will surely solve your problem.
Mine was with the 1st one and trying to figure out the problem, I focused onto the constellation.log and found that the message response after posting the contract was

Error performing API request: ApiSend (Send {sreqPayload = "\128@r4\128\NAKa\NUL\DLEW\NUL\128\253[P\247\128a\NUL\US\NUL9\NUL\243\NUL\128@r\EOT6\DLEIW\NUL5|\SOH\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\144\EOTc\255\255\255\255\SYN\128cSb\248\162\DC4NW\128c\225\203\SOR\DC4\140W[\NUL\128\253[4\128\NAKYW\NUL\128\253[Pv\EOT\128&6\ETX\129\SOH\144\128\128&5\144 \SOH\144\146\145\144PPP\180V[@Q\128\130\129R \SOH\145PP@Q\128\145\ETX\144\243[4\128\NAK\151W\NUL\128\253[P\158\194V[@q\128\130\129R \SOH\145PP@q\128\145\ETX\144\243[\NUL\129\NUL\129\144UP\145\144PV[`\NUL\128T\144P\144V\NUL\161ebzzr0X \231\217\146\148X\244\181Oo\236Gw,W*\179\210K\229\242\236e\CAN0RG\139\241l~\220\\NUL)", sreqFrom = "H8nD3HWE18/X8z+QJD/1rZwVa+g36sB3z0Qjr2vUfEA=", sreqTo = ["kCxDW9hTBdLHyT8qvPIca6HgDUCE3L8N7E+71gH6PQI="]}); sendRequest: Errors while running sendPayload: [Left "InvalidUrlException "http://35.237.250.163:9002push" "Invalid URL""]

If anything similar, try the above steps.

from quorum.

We also encountered the same problem, and the comment from @horca17 in this constellation issue thread(Consensys/constellation#85) fixed it.

on the first node, or the main node, config tm1.conf using only othernodes = [] and all other rnodes = ["https://127.0.0.1:9001/"], so constellation will work without errors.

HTH.

from quorum.