Conversation
| headEvent := make(chan core.ChainHeadEvent, 1) | ||
| backend.SubscribeChainHeadEvent(headEvent) | ||
| go func() { | ||
| var lastHead common.Hash | ||
| for ev := range headEvent { | ||
| if ev.Block.ParentHash() != lastHead { | ||
| cache.Purge() | ||
| } | ||
| lastHead = ev.Block.Hash() | ||
| } | ||
| }() |
There was a problem hiding this comment.
SAE never reorgs.
| headEvent := make(chan core.ChainHeadEvent, 1) | |
| backend.SubscribeChainHeadEvent(headEvent) | |
| go func() { | |
| var lastHead common.Hash | |
| for ev := range headEvent { | |
| if ev.Block.ParentHash() != lastHead { | |
| cache.Purge() | |
| } | |
| lastHead = ev.Block.Hash() | |
| } | |
| }() |
| BlockByNumber(ctx context.Context, number rpc.BlockNumber) (*types.Block, error) | ||
| SubscribeChainHeadEvent(ch chan<- core.ChainHeadEvent) event.Subscription | ||
| SubscribeChainAcceptedEvent(ch chan<- *types.Block) event.Subscription | ||
| LastAcceptedBlock() *types.Block |
There was a problem hiding this comment.
Why do we add LastAcceptedBlock? Isn't this just BlockByNumber(ctx, rpc.PendingBlockNumber)?
| ResolveBlockNumber(bn rpc.BlockNumber) (uint64, error) | ||
| HeaderByNumber(ctx context.Context, number rpc.BlockNumber) (*types.Header, error) | ||
| BlockByNumber(ctx context.Context, number rpc.BlockNumber) (*types.Block, error) | ||
| SubscribeChainHeadEvent(ch chan<- core.ChainHeadEvent) event.Subscription |
There was a problem hiding this comment.
I don't think we need SubscribeChainHeadEvent. We never have reorgs and it is only used for reorg detection.
| // getting no block and no error means we are requesting into the future | ||
| if block == nil { | ||
| if i == 0 { | ||
| return common.Big0, nil, nil, nil, nil | ||
| } | ||
| firstMissing = i | ||
| break | ||
| } |
There was a problem hiding this comment.
I don't think this is possible, is it?
Or are worried about this happening when we introduce state sync?
| if price.Cmp(oracle.cfg.MaxPrice) > 0 { | ||
| price = new(big.Int).Set(oracle.cfg.MaxPrice) | ||
| } | ||
| if price.Cmp(oracle.cfg.MinPrice) < 0 { | ||
| price = new(big.Int).Set(oracle.cfg.MinPrice) | ||
| } |
There was a problem hiding this comment.
I think we can use math.BigMin and math.BigMax here. They don't clone the values, but I also don't think there is any reason we clone the values here anyways.
| MaxPrice *big.Int `toml:",omitempty"` | ||
| MinPrice *big.Int `toml:",omitempty"` | ||
| MinGasUsed *big.Int `toml:",omitempty"` |
There was a problem hiding this comment.
MinGasUsed is unused
|
|
||
| var ( | ||
| reward = make([][]*big.Int, blocks) | ||
| baseFee = make([]*big.Int, blocks) |
There was a problem hiding this comment.
Are we deviating from the expected behavior here by not providing the next base fee? I know that we can't know it for sure, but we could return an upper-bound on the next block's base fee.
| type feeInfoProvider struct { | ||
| cache *lru.Cache | ||
| backend OracleBackend | ||
| newHeaderAdded func() // callback used in tests |
There was a problem hiding this comment.
I don't think we should be adding in code specific to testing in prod, we should figure out how to test our code through the exposed interface imo
| fc.cache, _ = lru.New(size + feeCacheExtraSlots) | ||
| // subscribe to the chain accepted event | ||
| acceptedEvent := make(chan *types.Block, 1) | ||
| backend.SubscribeChainAcceptedEvent(acceptedEvent) |
There was a problem hiding this comment.
This subscription leaks, do we need to expose shutdown logic somewhere?
| HeaderByNumber(ctx context.Context, number rpc.BlockNumber) (*types.Header, error) | ||
| BlockByNumber(ctx context.Context, number rpc.BlockNumber) (*types.Block, error) | ||
| SubscribeChainHeadEvent(ch chan<- core.ChainHeadEvent) event.Subscription | ||
| SubscribeChainAcceptedEvent(ch chan<- *types.Block) event.Subscription |
There was a problem hiding this comment.
If we are going to expose this SubscribeChainAcceptedEvent, would it make sense for all of the processing to be done in either initialize or in the subscription?
Right now I feel like there is kind of a mix of handling things in the subscription or on demand.
2 participants
No description provided.