database is closedissues related to our
OrderEventsubscribers blocking handling of messages.
BLOCK_POLLING_INTERVAL, we now attempt to sync as many blocks as necessary to reach the latest block available. This will reduce the chances of Mesh becoming out-of-sync with it's backing Ethereum node (#564)
ENABLE_ETHEREUM_RPC_RATE_LIMITINGand config option
enableEthereumRPCRateLimitingwhich can be used to completely disable Mesh's internal Ethereum RPC rate limiting features. By default it is enabled, and disabling can have some consequences depending on your RPC provider. (#584)
@0x/mesh-rpc-clientto avoid the client from hanging endlessly if it misses a response due to network disruption (#603).
@0x/mesh-browserpackage will now be able to retain orders and other relevant parts of the state when refreshing the page or closing and re-opening the browser. (#533).
OrderEventEndStateenum value to both
RPC_ADDRfrom a random available port to
60557. Some documentation already assumed
60557was the default port. Now all documentation has been updated for consistency with this change. (#542).
--archiveflag enabled. We now fast-sync only if less than 128 blocks have elapsed. Otherwise, we simply re-validate all orders and continue processing block events from the latest block. (#407)
localhost. Users who previously did not set
RPC_PORTmay need to now manually set
RPC_ADDRto enable other applications to access the RPC API. If you are using Docker Compose, we recommend using links. If you do need to set
RPC_ADDRto bind on
0.0.0.0, please be aware of the security implications and consider protecting access to Mesh via a third-party firewall. (See #444 and #487 for more details).
UNEXPIREDorder event kind which is emitted for orders that were previously considered expired but due to a block-reorg causing the latest block timestamp to be earlier than the previous latest block timestamp, are no longer expired. (#490)
networkis a misnomer here and what we actually care about is the
chainID. Most chains have the same id for their p2p network and chain. From the ones we support, the only outlier is Ganache, for which you will now need to supply
50(Learn more: https://medium.com/@pedrouid/chainid-vs-networkid-how-do-they-differ-on-ethereum-eec2ed41635b) (#485)
addOrdersAsyncfunction in the TypeScript bindings will be pinned.
txHasheskey in the
OrderEvents emitted from the
ordersJSON-RPC subscription and replaced it with
contractEvents, an array of decoded order-relevant contract events. Parsing these events allows callers to find every discrete order fill/cancel event. (#420)
EndStateto better elucidate that it represents the aggregate change to the orders state since it was last re-validated. As an end state, it does not capture any possible intermediate states the order might have been in since the last re-validation. Intermediate states can be inferred from the
getStatsAsyncin TS client
mesh_addOrderstreats orders that are already stored on the Mesh node. Previously, they would be rejected with code
OrderAlreadyStored. Now, if the order is stored and fillable, it will be accepted. If it is stored but unfillable, it will be rejected with
OrderAlreadyStoredAndUnfillable. We additionally added a
isNewproperty to the accepted orderInfos returned, so that callers can discern which orders Mesh already knew about. (#316)