0x-mesh icon indicating copy to clipboard operation
0x-mesh copied to clipboard

orderwatch: order rejected with OrderUnfunded, but it is funded

Open fabioberger opened this issue 5 years ago • 1 comments

There is currently a pretty bad footgun in how Mesh works internally that can lead to orders being rejected with status OrderUnfunded despite the allowances and balances being correctly set. What leads to this incongruity is the fact that Mesh is periodically syncing up to the latest block, and if it has not yet performed this sync, it continues to validate received orders at the previous latest block height it knows above. If the maker's balance / allowance has been updated in a subsequent block, Mesh doesn't know about those changes yet and therefore evaluates the order as unfunded.

A simple solution to this problem is to give Mesh some time to process the latest block after setting an allowance / balance. This can be done by introducing a sleep() in tests and by reducing the BLOCK_POLLING_INTERVAL so that the sleep doesn't need to be very long.

Ideally, Mesh would always validate orders at the latest block height. To do this would require updating the order watching logic from it's current "stop the world" design, an initiative that is being tracked here: https://github.com/0xProject/0x-mesh/issues/625

fabioberger avatar Feb 06 '20 15:02 fabioberger

If we just want to tackle the footgun in our tests, we may be able to draw from the solution in order_watcher_test.go. Instead of time.Sleep, these tests call blockWatcher.SyncToLatestBlock() followed by orderWatcher.WaitForAtLeastOneBlockToBeProcessed(ctx) (e.g. look inside setupOrderWatcher).

This won't always work in the general case because the order watcher may have already processed one block. However, it could likely be tweaked in order to be more generalized. If we go this route we could add this into the scenario package so that it waits for the block to be processed for you.

albrow avatar Apr 08 '20 23:04 albrow