mirror of https://github.com/embarklabs/embark.git
173d53de2f
Fix the proxy’s handling of WebSocket connections when subscribing to contract events and node data using the `eth_subscribe` RPC request. Previously, the client connection that the subscription data was sent to was often in a closed state. It was determined that this connection was the wrong connection to forward the data in the first place. The connection was in fact generally the connection created for the Ethereum service check which was then (correctly and subsequently) closed after it had finished its operation. The flow of a proxy request handling a WebSocket “eth_subscribe” RPC request is now as follows: 1. A WebSocket RPC request `”eth_subscribe”` is sent from a client to the proxy. 2. Proxy forwards the request to the node by way of a new instance of `RequestManager`. 3. When the node receives an event matching the subscription, it sends the event data back to same socket connection it received the request on (ie the specific instance of `RequestManager`). 4. The `RequestManager` fires the `”data”` event containing the subscription data, and this event is picked up in the proxy. 5. The proxy then forwards the subscription data on to the originating WS client connection. All other requests (ie non-WS or WS RPC requests that are not `eth_subscribe`) will be serviced to/from the node using a single `RequestManager` instance. Co-authored-by: Pascal Precht <pascal.precht@gmail.com> |
||
|---|---|---|
| .. | ||
| cockpit | ||
| core | ||
| embark | ||
| embarkjs | ||
| plugins | ||
| stack | ||
| utils | ||
| .yarnrc | ||