-
Notifications
You must be signed in to change notification settings - Fork 45
Conversation
31d5675
to
cc7a275
Compare
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 PR is pretty big. The most important changes happen within subscriber
and the ETH/EVM implementations in blockchain
.
@@ -1,176 +0,0 @@ | |||
package blockchain |
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.
Deleted because the current ETH implementation would replace this now, so no need to maintain two exact identical implementations.
If there ever is a need to change the implementation for BSC, we can bring it back again.
addresses := params.Addresses | ||
if len(params.Addresses) == 0 && params.Address != "" { | ||
addresses = []string{params.Address} | ||
} |
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.
Helper to select a single address if possible
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.
What about just always appending params.Address
to addresses if it is not empty? Also, what is the case of having 2 separate fields?
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.
We originally started by just having Addresses
, but on the CL side it makes more sense to only define a single address: Address
. Having support for both fields is more for backwards compatibility. Ideally, for more safety, I'd prefer users use the single address field.
@@ -5,7 +5,10 @@ import ( | |||
"errors" |
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.
Not included in this tier, so can be ignored
Request(t string) (response interface{}, err error) | ||
Subscribe(ctx context.Context, t string, ch chan<- interface{}) (err error) | ||
CreateJobRun(t string, v interface{}) (map[string]interface{}, error) | ||
Stop() | ||
} | ||
|
||
type FluxMonitorManager interface { | ||
Manager | ||
GetState(ctx context.Context) (*FluxAggregatorState, error) | ||
SubscribeEvents(ctx context.Context, ch chan<- interface{}) error | ||
CreateJobRun(roundId uint32) map[string]interface{} | ||
} | ||
|
||
type RunlogManager interface { | ||
Manager | ||
SubscribeEvents(ctx context.Context, ch chan<- RunlogRequest) error | ||
CreateJobRun(request RunlogRequest) map[string]interface{} |
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.
Instead of having a very generic interface with a lot of interface{}
types, I've split runlog and FM into two different interfaces, so they can be implemented more precisely and gives us more type safety.
@@ -1,20 +1,18 @@ | |||
package blockchain | |||
package evm |
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.
Since a lot of blockchains are EVM based, having an EVM package allows other blockchains to import the common functionality that they need.
"github.com/smartcontractkit/external-initiator/blockchain/common" | ||
|
||
eth "github.com/ethereum/go-ethereum/common" |
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.
After going down a rabbit hole online, I've learned that dot-imports (which I had planned for our internal common
package) is not a good thing to use, and should only ever be used in tests.
Instead, the GETH common package is imported as eth
.
addresses := params.Addresses | ||
if len(params.Addresses) == 0 && params.Address != "" { | ||
addresses = []string{params.Address} | ||
} |
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.
What about just always appending params.Address
to addresses if it is not empty? Also, what is the case of having 2 separate fields?
RequestId string | ||
CallbackFunction string | ||
} | ||
type RunlogRequest map[string]interface{} |
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.
Why making it generic?
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.
Because all fields here ended up in what was previously the Params
field anyways, so with the previous struct the values went a lot back-and-forth, and for new blockchain implementations, this list would just grow never ending.
"math/big" | ||
"net/url" | ||
"strings" | ||
"time" | ||
|
||
common2 "github.com/smartcontractkit/external-initiator/blockchain/common" |
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 this be renamed or maybe rename the geth package to eth
as above?
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 will be fixed once we reach this part of the migration
js := &store.JobSpec{ | ||
Job: req.JobID, | ||
Spec: req.Params.FluxMonitor, | ||
Spec: spec, |
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.
Nice. So we are storing the whole actual JobSpec here, right? Both for RL and FM.
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.
Correct
services/fluxmonitor.go
Outdated
@@ -40,32 +40,32 @@ type FluxMonitorConfig struct { | |||
func ParseFMSpec(jsonSpec json.RawMessage, runtimeConfig store.RuntimeConfig) (FluxMonitorConfig, error) { | |||
var fmConfig FluxMonitorConfig | |||
|
|||
res := gjson.GetBytes(jsonSpec, "feeds.#.url") | |||
res := gjson.GetBytes(jsonSpec, "fluxmonitor.feeds.#.url") |
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.
Maybe keep only the fluxmonitor part before starting parsing? In order to not duplicate the fluxmonitor.
below
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.
I initially wanted to do that, but wasn't able to get what I was looking for. Do you know how to do this with gjson?
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.
Something like
jsonSpec = []byte(gjson.GetBytes(jsonSpec, "fluxmonitor").Raw)
or rename it to fmSpec
@@ -130,22 +130,16 @@ func NewFluxMonitor(job string, config FluxMonitorConfig, triggerJobRun chan sub | |||
|
|||
FAEvents := make(chan interface{}) | |||
|
|||
state, err := fm.blockchain.Request(common.FMRequestState) | |||
state, err := fm.blockchain.GetState(context.TODO()) |
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.
How do you envision this context.TODO()
to be used?
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.
We'll define the request timeouts here, instead of having the blockchains define them. I'll make an issue for this.
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.
client/service.go
Outdated
js, err := srv.store.LoadJobSpec(sub.Job) | ||
if err != nil || js == nil { | ||
if err != nil || gjson.GetBytes(js.Spec, "fluxmonitor").Raw == "null" { | ||
startService = srv.subscribeRunlog |
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.
Why not calling service, err := srv.subscribeRunlog(sub, triggerJobRun, js)
here directly?
Instead of implementing Starter type etc.
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.
Good question, I'll change this.
f6a5102
to
7495a92
Compare
fmConfig.Multiply = int32(gjson.GetBytes(jsonSpec, "fluxmonitor.precision").Int()) | ||
fmConfig.Threshold = gjson.GetBytes(jsonSpec, "fluxmonitor.threshold").Float() | ||
fmConfig.AbsoluteThreshold = gjson.GetBytes(jsonSpec, "fluxmonitor.absoluteThreshold").Float() | ||
fmConfig.RequestData = fmSpec.Get("requestData").Raw |
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.
Nice!
No description provided.