-
Notifications
You must be signed in to change notification settings - Fork 111
orderwatch: Use consistent asynchronous API #307
Conversation
@@ -112,9 +112,6 @@ func SetupOrderStream(ctx context.Context, app *core.App) (*ethRpc.Subscription, | |||
|
|||
for { | |||
select { | |||
case <-ctx.Done(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixes a bug in #304 that was previously unnoticed. ctx
here is not something we control and it seems to be canceled even though a client is still actively subscribed. I can't find any documentation about the expected behavior of ctx
at https://godoc.org/github.com/ethereum/go-ethereum/rpc. For now, we have no real choice but to ignore the given context.
zeroex/orderwatch/order_watcher.go
Outdated
FillableTakerAssetAmount: orderInfo.FillableTakerAssetAmount, | ||
Kind: zeroex.EKOrderExpired, | ||
} | ||
w.orderFeed.Send([]*zeroex.OrderEvent{orderEvent}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An optimization here would be to append each OrderEvent
to a slice and then send them all to orderFeed
after the for loop has finished executing.
8a1ee5b
to
41fffa6
Compare
zeroex/orderwatch/order_watcher.go
Outdated
logger.WithFields(logger.Fields{ | ||
"error": err.Error(), | ||
"orderHash": expiredOrder.ID, | ||
}).Warning("Order expired that was no longer in DB") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we keep this as a Warning
or lower this to a Trace
? It is expected to happen from time to time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. Good idea.
related to #96.